EAP-Kerberos - Kerberos

This is a discussion on EAP-Kerberos - Kerberos ; 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: EAP-Kerberos

  1. EAP-Kerberos

    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 Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: EAP-Kerberos

    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
    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


  3. Re: EAP-Kerberos

    >>>>> "Saber" == Saber Zrelli 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 Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: EAP-Kerberos


    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 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
    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


  5. Re: EAP-Kerberos

    >>>>> "Saber" == Saber Zrelli 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 Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  6. Re: EAP-Kerberos

    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

+ Reply to Thread