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: 614-853-0091 > Skype: wifi_chris > > http://www.netsteady.cc > ________________________________________________ Kerberos mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/kerberos |
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 |
In reply to this post by Markus Moeller
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 |
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 |
In reply to this post by NetSteady
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 ________________________________________________ Kerberos mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/kerberos |
>>>>> "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 |
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 |
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. 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 |
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. ________________________________________________ Kerberos mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/kerberos |
In reply to this post by Markus Moeller
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: 614-853-0091 Skype: wifi_chris http://www.netsteady.cc ________________________________________________ Kerberos mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/kerberos |
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. ________________________________________________ Kerberos mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/kerberos |
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 |
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 |
Free forum by Nabble | Edit this page |