Subject: Re: Kerberos for Wireless Authentication

From: Saber Zrelli <[email-masked]>
Date: Thu, 02 Jun 2005 19:21:11 +0900

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: 614-853-0091
> Skype: wifi_chris
> Email: cmhutch [at] netsteady.cc
> 
> http://www.netsteady.cc
> 
> ________________________________________________
> Kerberos mailing list           [email-masked]
> https://mailman.mit.edu/mailman/listinfo/kerberos

-- 
Saber ZRELLI <[email-masked]>
Japan Advanced Institute of Science and Technology
Center of Information Science
Shinoda Laboratory
url     : http://www.jaist.ac.jp/~zrelli
gpg-id  : 0x7119EA78

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Jun 2005 12:13:59 -0400

>>>>> "Saber" == Saber Zrelli <[email-masked]> 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.

---

From: Saber Zrelli <[email-masked]>
Date: Sat, 04 Jun 2005 03:10:12 +0900

Hi , 

> 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.

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 03 Jun 2005 14:21:16 -0400

> 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

---

From: Sam Hartman <[email-masked]>
Date: Fri, 03 Jun 2005 15:06:59 -0400

>>>>> "Saber" == Saber Zrelli <[email-masked]> writes:

    Saber> Hi ,

    >> 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.

---

From: Matt Crawford <[email-masked]>
Date: Mon, 06 Jun 2005 09:27:51 -0500

>> 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.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Jun 2005 09:59:56 -0500

> Work area for energetic contributors, yes.  Milestones of the group, 

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
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 06 Jun 2005 12:46:39 -0400

> 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) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA