EAP-Kerberos

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

EAP-Kerberos

Thomas Otto
Hi Chris, Saber, Sam, all,

I read your discussion in the Kerberos Mailing List regarding
Kerberos for Wireless Authentication (June 2005).

In February 05, I already thought a little bit about using
Kerberos as single logon for both
* gaining access to a wireless network  and
* using the offered kerberized services,
so that I began writing an EAP method which uses Kerberos,
(the draft is at http://www-public.tu-bs.de:8080/~y0013790/ ,
but so dramatically immature that it is not worth to be
read ;-).

There are generally two ways how to apply Kerberos to WLAN
authentication:

1) The user has nothing but his username/password. The EAP-
conversation is carried out in order to authenticate at the
AS and to get a TGT.
From this point, the client uses this TGT to request the TGS
for service tickets.

2) The user has already network access and a TGT. In this case,
the authenticator (access point) is a service, so that the
goal is to get a service ticket for the service "access point,
wireless network access".
Therefore, a proxy Kerberos Server is inside the access point
and talks EAP to the client, and talks in the other direction
over IP with the Kerberos TGS. (I think this is covered by
an older proposal, EAP-GSS).

Case 1 is interesting. It would be nice if a user, types only
once, namely at the initial logon, his username password, and
subsequently get access to the network and the therein
advertised services.

Is this situation realistic?
Where could one use Kerberos in wireless authentication otherwise?

I'd be glad if you tell me your ideas, and especially if you see the
need for an EAP Kerberos method.

Best regards,
Thomas

PS.
I'm aware of the property catalogue for an EAP method, which is intended
to be used in wireless networks ( http://www.ietf.org/rfc/rfc4017.txt ).
The major issue is the dictionary attack problem, but I think it could be
mitigated by using some strong password protocol (like the paper of Wu it proposes).


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: EAP-Kerberos

Sam Hartman-5
In general you want to combine case 1 and case 2.  So that if the user
has no ticket you get one, then you use that to get a ticket for the
accesspoint.  You certainly never want to give the access point or EAP
server the password.

I'd recommend talking to Derek Atkins about your proposal.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: EAP-Kerberos

Saber Zrelli
In reply to this post by Thomas Otto
Hi Thomas ,

Thank you for your concern ,

following are some thoughts about this topic :

IMHO, what makes wireless networks an interesting topic when
considering Authentication is the mobile connectivity which is
technically implemented by "roaming" and handovers. These two
properties make wireless clients different from fixed IP clients. I
think that proxying Kerberos ( at AS or gateways) is not specific to
wireless networks, someone might require dynamic address allocation
and bootstrapping of fixed hosts and use bootstrapping protocols in
addition to proxying Kerberos authentication at the network's
borders (like in Dial-In network access providers).

when some visiting user would like to connect to a foreign wireless
network, In addition to the bootstrapping problem, the actual
protocol defined by IAKERB does not allow the operator to
authenticate the visiting user since he/she is not registered in
the local DB. Hence there is need to extend the proxy properties to
perform inter-realm operations (to communicate with the user's home
realm ) for authenticating roaming users.

The EAP-KERBEROS method would allow the use of Kerberos in several
EAP based frameworks ( IPSEC, PANA ..) but would not completely
solve the problem of Kerberos-based authentication in wireless
networks.

The advantage of other EAP methods compared to EAP-Keeberos (in
roaming situations )is that an EAP-TLS authenticator for ex, would
communicate with the client's home realm. in Kerberos this is not
possible without extensions to the base protocol.

> In February 05, I already thought a little bit about using
> Kerberos as single logon for both * gaining access to a wireless
> network  and * using the offered kerberized services, so that I
> began writing an EAP method which uses Kerberos, (the draft is at
> http://www-public.tu-bs.de:8080/~y0013790/ , but so dramatically
> immature that it is not worth to be read ;-).
>
> There are generally two ways how to apply Kerberos to WLAN
> authentication:
>
> 1) The user has nothing but his username/password. The EAP-
> conversation is carried out in order to authenticate at the AS and
> to get a TGT. From this point, the client uses this TGT to request
> the TGS for service tickets.
>
> 2) The user has already network access and a TGT.
If the user has network access then why does he need to go through a
proxy.

> In this case, the authenticator (access point) is a service, so
> that the goal is to get a service ticket for the service "access
> point, wireless network access".

The service offered by the access point is attachement to the fixed
network and allocation of an IP address.

> Ttherefore, a proxy Kerberos Server is inside the access point and
> talks EAP to the client, and talks in the other direction over IP
> with the Kerberos TGS. (I think this is covered by an older
> proposal, EAP-GSS).

If I well understood scenario 2 : The user have a TGT but no network
access ( this happen on handovers at IP level such as in MIPV6 with
necessity of IP address re-allocation at each handover ).

As the Access network is considered as a service, the client uses
the proxy (and EAP-Kerberos) to obtain a service ticket from the TGS.

 
> Case 1 is interesting. It would be nice if a user, types only
> once, namely at the initial logon, his username password, and
> subsequently get access to the network and the therein advertised
> services.
>
> Is this situation realistic? Where could one use Kerberos in
> wireless authentication otherwise?

I think this is the advantage of using kerberos in Access networks.
The fact that a ticket is valid for a certain period of time allows
fast handovers by using the same ticket several times without
requiring communication with the back-end KDCs.  


>
> I'd be glad if you tell me your ideas, and especially if you see
> the need for an EAP Kerberos method.
>
> Best regards, Thomas
>
> PS. I'm aware of the property catalogue for an EAP method, which
> is intended to be used in wireless networks (
> http://www.ietf.org/rfc/rfc4017.txt ). The major issue is the
> dictionary attack problem, but I think it could be mitigated by
> using some strong password protocol (like the paper of Wu it
> proposes).
>
>

--
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
Reply | Threaded
Open this post in threaded view
|

Re: EAP-Kerberos

Sam Hartman-5
>>>>> "Saber" == Saber Zrelli <[hidden email]> writes:

    Saber> when some visiting user would like to connect to a foreign
    Saber> wireless network, In addition to the bootstrapping problem,
    Saber> the actual protocol defined by IAKERB does not allow the
    Saber> operator to authenticate the visiting user since he/she is
    Saber> not registered in the local DB. Hence there is need to
    Saber> extend the proxy properties to perform inter-realm
    Saber> operations (to communicate with the user's home realm ) for
    Saber> authenticating roaming users.

For the record, I strongly disagree with the above.

I don't have time to explain now, but will try to get to it reasonably soon.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: EAP-Kerberos

Saber Zrelli

Hi ,

In the IAKERB draft, the followins is said :

 ===========

6. The IAKERB proxy protocol :
...
The IAKERB proxy is responsible for locating an appropriate KDC using the realm
information in the KDC request message it received from the client.
...
 ============

I appologize for my misleading affirmation, The IAKERB proxy can
be used by the client to obtain cross realm ticket that can be used
in the visited realm.

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.

Best Regards,
Saber.

* On 21:55, Sun 17 Jul 05, Sam Hartman wrote:

> >>>>> "Saber" == Saber Zrelli <[hidden email]> writes:
>
>     Saber> when some visiting user would like to connect to a foreign
>     Saber> wireless network, In addition to the bootstrapping problem,
>     Saber> the actual protocol defined by IAKERB does not allow the
>     Saber> operator to authenticate the visiting user since he/she is
>     Saber> not registered in the local DB. Hence there is need to
>     Saber> extend the proxy properties to perform inter-realm
>     Saber> operations (to communicate with the user's home realm ) for
>     Saber> authenticating roaming users.
>
> For the record, I strongly disagree with the above.
>
> I don't have time to explain now, but will try to get to it reasonably soon.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: EAP-Kerberos

hartmans
>>>>> "Saber" == Saber Zrelli <[hidden email]> writes:

    Saber> I was referring to a KDC instead of an IAKERB proxy. My
    Saber> thoughts are that these proxying functionalities should be
    Saber> moved to the KDC of the visited realm. But this would be
    Saber> another topic that I wish to start soon.

Another point on which I strongly disagree.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: EAP-Kerberos

Jeffrey Altman-3
In reply to this post by Saber Zrelli
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos