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 Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos -- Saber ZRELLI <[EMAIL PROTECTED]> 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 Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos