Re: Kerberos for Wireless Authentication

[Markus Moeller]

Chris,

I would think it is a good idea as in  theory any Windows system uses
Kerberos already and on a Unix platform keytabs could be used. There was a
draft for eap gss
http://www.watersprings.org/pub/id/draft-aboba-pppext-eapgss-12.txt and it
seems some are looking at eap kerberos
http://www-public.tu-bs.de:8080/~y0013790/draft-someone-eap-kerberos-00.txt

Regards
Markus


<[hidden email]> wrote in message
news:[hidden email]...

> Good Day,
>
> My name is Chris Hutchison, CEO of NetSteady Communications, Ltd. in
> Columbus, Ohio. We are an IT firm that has been working on a product
> that will give Kerberos functionality to existing RADIUS servers (from
> Funk, Meetinghouse, Cisco, etc) that are used for wireless
> authentication.
>
> I wanted to see how many people think that this functionality would be
> helpful in their enterprise, or if I should head a different direction
> altogether with it.
>
> Please feel free to contact me at [hidden email] or [hidden email]
>
> Thank you,
> Chris Hutchison
>
> - - - - - - - - - - - - - - - - - - - -
> Christopher M. Hutchison, CEO
> NetSteady Communications, Ltd.
> P.O. Box 392
> Galloway, Ohio 43119
>
> Phone: [phone]
> Skype: wifi_chris
>
> http://www.netsteady.cc
>

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

[Sam Hartman-5]

Please don't use the eapgss stuff.  It has received very negative
reviews from the Kerberos and GSS community who were not involved in
its design.

There may be a future eap gss mechanism that is well done, but it will
depend on ongoing work in the kitten working group.

Too my knowledge eap krb5 has not been reviewed by the Kerberos
community within the IETF either.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

[NetSteady]

Actually, our product doesn't require EAP-GSS, nor EAP-Kerberos.

Instead, we use existing, popular authentication mechanisms to provide
kerberos functionality to mainstream RADIUS servers. There is no
additional software required other than the EAP supplicant, and the
client doesn't even realize that they're authenticating to anything
different.

Our product doesn't even need Kerberos for Windows in order to
authenticate the client to the Kerberos Database.

That being said, we do not currently have the capability to pass the
ticket on to the client. Our software is simply for authenticating
kerberos credentials against the server.

Any other thoughts?

Chris
- - - - - - - - - - - - - - - - - - - -
Christopher M. Hutchison, CEO
NetSteady Communications, Ltd.
P.O. Box 392
Galloway, Ohio 43119

Phone: [phone]
Skype: wifi_chris
Email: cmhutch [at] netsteady.cc

http://www.netsteady.cc

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

[Jeffrey Altman-3]

NetSteady wrote:

> Actually, our product doesn't require EAP-GSS, nor EAP-Kerberos.
>
> Instead, we use existing, popular authentication mechanisms to provide
> kerberos functionality to mainstream RADIUS servers. There is no
> additional software required other than the EAP supplicant, and the
> client doesn't even realize that they're authenticating to anything
> different.
>
> Our product doesn't even need Kerberos for Windows in order to
> authenticate the client to the Kerberos Database.
>
> That being said, we do not currently have the capability to pass the
> ticket on to the client. Our software is simply for authenticating
> kerberos credentials against the server.
>
> Any other thoughts?

I would argue that you are not really using Kerberos.   If the
client is sending user/password data to the server all you are
doing is using Kerberos to perform a database lookup.   This
technique is frequently used as a means of providing single password
functionality to an organization but it is not Kerberos.

Jeffrey Altman


--
-----------------
This e-mail account is not read on a regular basis.
Please send private responses to jaltman at mit dot edu
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

[Saber Zrelli]

Hi Chris, All

My name is Saber, and I'm working on a topic very close to what you
described in your e-mail to the kerberos wg.

If I well understood,  

your system is for authenticating wireless clients in access
networks. These clients I suppose might be in their home network or
in a roaming situation.

Then you have a back-end AAA system(RADIUS/Diameter). And you are
planning to use the back-end AAA system for providing Kerberos
credentials to wireless clients.

The problem then is between the NAS and the wireless clients.

When using EAP , the client and the NAS can use PANA or 802.1X to
perform the authentication at L3. But if you use just kerberos,
there is no existent mechanism that transports kerberos messages
between a NAS and a wireless client.

There is however a draft called "IAKERB"  that provides pass-through
authentication using kerberos
(http://watersprings.org/pub/id/draft-ietf-cat-iakerb-08.txt), that
can do the trick.


I would like to profit from this occasion to expose what I'm
concerned about which is the back-end AAA operations. Imagine that
you are in a roaming situation and that you need to have cross-realm
TGT ticket or just a service ticket.

The actual Kerberos mechanism for cross-realm opertaions is not
compatible with AAA schemas, this is because Kerberos was not
designed to be a part of an AAA framework such as RADIUS or
Diameter.

In order to make Kerberos easily integrated with RADIUS for
instance, there should be an inter-KDC protocol.

In my current work I'm designing an inter-KDC protocl that will be
integrated as a Diameter extension ( just like Diameter-EAP
extension ). My proposed version of kerberos cross realm operations
will make kerbeors -among other advantages- suitable for wireless
and roaming situations.

If you are interested on this topic, you can find more details about
it here :
http://www.jaist.ac.jp/~zrelli/zrelli/thesis/draft-zrelli-kerberos-cross-prop.html


I will be glad to receive your comments on it.

PS : This document is in early draft stage, several parts are not
finished yet, but the reader should be able  understand the general
Idea behind it.



Regards.

---Saber


* On 05:47, Wed 01 Jun 05, NetSteady wrote:

> Actually, our product doesn't require EAP-GSS, nor EAP-Kerberos.
>
> Instead, we use existing, popular authentication mechanisms to provide
> kerberos functionality to mainstream RADIUS servers. There is no
> additional software required other than the EAP supplicant, and the
> client doesn't even realize that they're authenticating to anything
> different.
>
> Our product doesn't even need Kerberos for Windows in order to
> authenticate the client to the Kerberos Database.
>
> That being said, we do not currently have the capability to pass the
> ticket on to the client. Our software is simply for authenticating
> kerberos credentials against the server.
>
> Any other thoughts?
>
> Chris
> - - - - - - - - - - - - - - - - - - - -
> Christopher M. Hutchison, CEO
> NetSteady Communications, Ltd.
> P.O. Box 392
> Galloway, Ohio 43119
>
> Phone: [phone]
> Skype: wifi_chris
> Email: cmhutch [at] netsteady.cc
>
> http://www.netsteady.cc
>
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos

--
Saber ZRELLI <[hidden email]>
Japan Advanced Institute of Science and Technology
Center of Information Science
Shinoda Laboratory
url     : http://www.jaist.ac.jp/~zrelli
gpg-id  : 0x7119EA78
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

[Sam Hartman-5]

>>>>> "Saber" == Saber Zrelli <[hidden email]> writes:

    Saber> There is however a draft called "IAKERB" that provides
    Saber> pass-through authentication using kerberos
    Saber> (http://watersprings.org/pub/id/draft-ietf-cat-iakerb-08.txt),
    Saber> that can do the trick.
Note that this draft has been rejected by this working group and is no
longer an ongoing effort.  Some party could choose to fix the problems
in that draft and attempt to bring it back, but last time this came up
no one offered to do that work.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

[Saber Zrelli]

Hi ,

* On 12:13, Thu 02 Jun 05, Sam Hartman wrote:

> >>>>> "Saber" == Saber Zrelli <[hidden email]> writes:
>
>     Saber> There is however a draft called "IAKERB" that provides
>     Saber> pass-through authentication using kerberos
>     Saber> (http://watersprings.org/pub/id/draft-ietf-cat-iakerb-08.txt),
>     Saber> that can do the trick.
> Note that this draft has been rejected by this working group and is no
> longer an ongoing effort.  Some party could choose to fix the problems
> in that draft and attempt to bring it back, but last time this came up
> no one offered to do that work.

I think that the problem tagetted by IAKERB are a big obstacle that
limit the scenarions where Kerberos can be used.

Specially, concerning wireless access networks, Kerberos can be very
convenient due to the fact that tickets have life-times, which means
that clients do not need to ride the full authentication path each
time they perform a hand-over. Current methods based on EAP, are
defining context transfer protocols to attack the problem related to
the latency of handovers ( CTP for PANA in PANA wg ). Kerberos IMHO,
can offer fast handover in wireless access networks, but it requires
some complementary protocols such as IAKERB.  

I really think that working on this axis should be amongst the
milestones of kerberos wg.


Regards.

--
Saber ZRELLI <[hidden email]>
Japan Advanced Institute of Science and Technology
Center of Information Science
Shinoda Laboratory
url     : http://www.jaist.ac.jp/~zrelli
gpg-id  : 0x7119EA78
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

[Jeffrey Altman]

Saber Zrelli wrote:

> I think that the problem tagetted by IAKERB are a big obstacle that
> limit the scenarions where Kerberos can be used.
>
> Specially, concerning wireless access networks, Kerberos can be very
> convenient due to the fact that tickets have life-times, which means
> that clients do not need to ride the full authentication path each
> time they perform a hand-over. Current methods based on EAP, are
> defining context transfer protocols to attack the problem related to
> the latency of handovers ( CTP for PANA in PANA wg ). Kerberos IMHO,
> can offer fast handover in wireless access networks, but it requires
> some complementary protocols such as IAKERB.  
>
> I really think that working on this axis should be amongst the
> milestones of kerberos wg.

There is only so much that the active members of the working group
can work on at a given time.   If members of the wireless community
were to participate in the working group, it would increase the amount
of work that can be accomplished.

Jeffrey Altman

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

[Sam Hartman-5]

>>>>> "Saber" == Saber Zrelli <[hidden email]> writes:

    Saber> Hi ,

    Saber> * On 12:13, Thu 02 Jun 05, Sam Hartman wrote:
    >> >>>>> "Saber" == Saber Zrelli <[hidden email]> writes:
    >>
    Saber> There is however a draft called "IAKERB" that provides
    Saber> pass-through authentication using kerberos
    Saber> (http://watersprings.org/pub/id/draft-ietf-cat-iakerb-08.txt),
    Saber> that can do the trick.
    >> Note that this draft has been rejected by this working group
    >> and is no longer an ongoing effort.  Some party could choose to
    >> fix the problems in that draft and attempt to bring it back,
    >> but last time this came up no one offered to do that work.

    Saber> I think that the problem tagetted by IAKERB are a big
    Saber> obstacle that limit the scenarions where Kerberos can be
    Saber> used.

True, but it's not going to happen unless someone has time to do it.
The people currently involved in the kerberos wg don't have that time.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

[NetSteady]

All,

I completely agree that we are merely using kerberos for a database
lookup, but at this point, there is no real way to authenticate to
kerberos for wireless networks. We will continue to look for a way to
forward the kerberos tickets to the clients, but at this point, we're
pretty excited about creating this functionality for non-kerberized
servers.

Once our product is fully available, I'll make a major announcement
here, and through many other news sources. If you have any suggestions
or other thoughts, please feel free to contact me at:

cmh[at]netsteady.cc

Chris Hutchison
- - - - - - - - - - - - - - - - - - - -
Christopher M. Hutchison, CEO
NetSteady Communications, Ltd.
P.O. Box 392
Galloway, Ohio 43119

Phone: [phone]
Skype: wifi_chris

http://www.netsteady.cc

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

[Matt Crawford]

>> I really think that working on this axis [IAKERB/Wireless Auth.]
>> should be amongst the milestones of kerberos wg.

Work area for energetic contributors, yes.  Milestones of the group,
no.  IMO, of course.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

[Nicolas Williams]

On Mon, Jun 06, 2005 at 09:27:51AM -0500, Matt Crawford wrote:
> >>I really think that working on this axis [IAKERB/Wireless Auth.]
> >>should be amongst the milestones of kerberos wg.
>
> Work area for energetic contributors, yes.  Milestones of the group,
> no.  IMO, of course.

Such a mechanism could be pursued outside the KRB WG, either as an
individual submission or in another WG (AAA?), and it could receive
expert review from Kerberos V experts when and as needed.

Don't let us slow you down.

Nico
--
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

[Jeffrey Hutzelman]

On Monday, June 06, 2005 09:59:56 AM -0500 Nicolas Williams
<[hidden email]> wrote:

> On Mon, Jun 06, 2005 at 09:27:51AM -0500, Matt Crawford wrote:
>> >> I really think that working on this axis [IAKERB/Wireless Auth.]
>> >> should be amongst the milestones of kerberos wg.
>>
>> Work area for energetic contributors, yes.  Milestones of the group,
>> no.  IMO, of course.
>
> Such a mechanism could be pursued outside the KRB WG, either as an
> individual submission or in another WG (AAA?), and it could receive
> expert review from Kerberos V experts when and as needed.

IAKERB or something like it is clearly within the scope of this working
group; it was an "existing proposal" at the time the WG was formed.  There
is no milestone because the group decided to drop the proposal, for various
reasons.  As others have noted, one of the main reasons why no work has
been done recently in that space is because potential contributors are
currently involved in other work, and only have so much time.

If there are folks that want to reopen IAKERB, are willing to spend time on
it, and can convince the WG that this is the right approach, then I see no
problem with carrying on such work here.  Of course, I would expect any
GSSAPI mechanism work to be reviewed in KITTEN as well.  I think it would
be ill-advised to pursue any such work as an indiviudal without input from
one or both of these working groups.



A while back there was a proposal for a Kerberos EAP method which would
have supported tunneling of Kerberos messages in a similar fashion to EAP,
allowing a client to communicate with its KDC to obtain credentials needed
for EAP authentication.  This looked somewhat promising, and possibly a
better fit for network access applications than IAKERB, but to my knowledge
no work has been done on this in a while.

It's not clear to me that work on an EAP method is in scope for this WG,
though I'd be inclined towards "yes" by analogy to IAKERB.  Perhaps Sam
would be willing to comment on this point.  It clearly is not in scope for
the EAP WG, whose charter does not currently include standardizing new EAP
methods.  However, I would expect any actual work in this area to be
reviewed in both WG's, even if pursued as individual work.  Again, I think
it would be ill-advised to pursue such work without input from members of
one or both WG's.


I do not believe that either type of mechanism is within the scope of the
AAA working group, though a Diameter extension to tunnel krb5 messages
between Diameter servers likely would be.  Those determinations are
ultimately up to the AAA chairs and the OPS AD's.


An extension to the Kerberos protocol such as Saber Zrelli proposed is
clearly not within the scope of AAA.  Any such work should be done within
the Kerberos WG; I would not expect approval of a standards-track extension
to Kerberos that had passed review here.  Note that in order to convince
this WG to take on such work, you will need to convince us that extending
Kerberos is the right way of solving the problem you describe, and that
your propsed extension is the right one.  If you want it to happen in a
timely fashion, it of course would help to bring along people willing to do
some of the work (protocol design, document editing, etc); preferably such
people should be familiar with the Kerberos protocol and with the needs of
network operators with respect to the problem you are trying to solve.


-- Jeffrey T. Hutzelman (N3NHS) <[hidden email]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos