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/zrell...ross-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
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