Re: Kerberos for Wireless Authentication

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos for Wireless Authentication

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: 614-853-0091
> 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


Reply | Threaded
Open this post in threaded view
|

Re: Kerberos for Wireless Authentication

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.



Reply | Threaded
Open this post in threaded view
|

Re: Kerberos for Wireless Authentication

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


Reply | Threaded
Open this post in threaded view
|

Re: Kerberos for Wireless Authentication

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

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos for Wireless Authentication

Sam Hartman-5
In reply to this post by Saber Zrelli
>>>>> "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.



Reply | Threaded
Open this post in threaded view
|

Re: Kerberos for Wireless Authentication

Matt Crawford
In reply to this post by Jeffrey Altman
>> 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.



Reply | Threaded
Open this post in threaded view
|

Re: Kerberos for Wireless Authentication

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


Reply | Threaded
Open this post in threaded view
|

Re: Kerberos for Wireless Authentication

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