Hello , I think that authentication operations should be centralized. I mean by centralized that the whole access network and the access server should rely on a single entity to obtain authentication for users from local realm and roaming users.
This schema is more extendable and more organized that having each AS to perform a DNS lookup to contact a remote realm's KDC. IMHO, in wireless environments, the AS should not perform cross realm operations. Centralizing the "proxying" in the visited realm's KDC would allow better use of caching and would be more compliant with cross realm AAA operations as defined by protocols AAA wg such as Diameter and PANA. The standard schema beeing developed for wireless access networks is to have PANA/802.11X as bootstrapping mechanism between the client and the AS. The bootstrapping protocol encapsulates an EAP authentication method ( such as EAP-TLS). The AS would act as pass-through ( or Authenticaion agent) for the EAP protocol and deliver the EAP packets to the local AAA server using an AAA protocol (such as Diameter-EAP extension). The local AAA server would then process EAP requests locally or forward them to remote AAA servers in other realms. ( see draft-ietf-pana-framework-05.txt section.3 ) IMHO, If we want to use kerberos in access networks, it would be better to follow the schema described above. This means that Kerberos requests should be forwarded to the visited realm's KDC and from there cross realm operations take place to authenticate the user. This would allow the use of PANA for ex, to bootstrap clients using EAP-kerberos as an authentication method. As PANA , not like IAKERB, only forwards to the local AAA server ( which btw would implement EAP-kerberos and will have a KDC runnig on it ). I already have started a proposal on how to use kerberos for cross realm operations such as it is easy to integrate kerberos in actual AAA frameworks. Here is the link : http://www.jaist.ac.jp/~zrelli/zrelli/thesis/draft-zrelli-kerberos-cross-prop.html I would be very glad to receive your comments on it even though it is not mature yet. Best Regards, Saber. * On 17:55, Tue 19 Jul 05, Jeffrey Altman wrote: > Saber Zrelli wrote: > > I was referring to a KDC instead of an IAKERB proxy. My thoughts are > > that these proxying functionalities should be moved to the KDC of > > the visited realm. But this would be another topic that I wish to > > start soon. > > Why would you want to have the KDC from one realm act as a proxy to > other realms? > > You already have a proxy that will be communicating with the KDC > from the local realm. Why wouldn't that proxy act like a normal > Kerberos client and communicate with each of the realms necessary > to obtain service tickets for the source client? > > Jeffrey Altman > ________________________________________________ > 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