[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Radius authentication and client configuration

> Your comments are correct and what I would like to do is to generalize
> the Extended Authentication draft by defining how this extra
> authentication can happen in all applications and then include an
> appendix on how to use it inside ISAKMP.
> 
> But, you may say, EAP already does this...
> 
> After reading EAP many times now, I still believe that it is not as
> powerful as XAUTH (draft-ietf-ipsec-isakmp-xauth-01.txt).  While it uses
> the same mechanisms (request/reply) as in XAUTH and some of the same
> authentication mechanisms, it doesn't allow for some of the flexibility
> of XAUTH.  
> 
> Here are some of my concerns with EAP:
> 
>  - EAP currently uses an 8-bit identifier.  I believe this is too small
> and will lead to overlap on very busy servers.  XAUTH uses 16 bits.
> 
>  - Only one data type may be requested/replied within one payload.
> XAUTH allows for multiple data types to be sent across within one
> payload.  For example, when using RADIUS authentication, the mobile
> client sends back his user name and his password all in the same reply
> message in two data types (attributes).
> 
>  - EAP doesn't allow for multiple authentication requests within the
> same authentication.  SecureID has a NextPIN mode that requests the next
> passcode from the card after the first passcode was verified.  This adds
> extra confidence that the user really is in possession of the card.
> 
>  - EAP uses different format for each data type while XAUTH uses
> standard attributes formats for all data types.
> 
>  - Some requests/replies in EAP are not specified in great detail.  Take
> for instance the Generic Token Card;  The data isn't defined very well.
> You will need their user id (if you haven't gotten it from somewhere
> else), their password and then the token card's passcode.  The current
> EAP document doesn't state any of this and thus prevents the use of EAP
> in an implementation.
> 
> Let me just state that I don't care what mechanism we (IPSec working
> group) use to accomplish this problem, just that it is a standard
> mechanism and it works correctly.  

If EAP needs to be fixed, this is the right time. It is currently sitting on
the IESG's pending list and if changes are needed we need to bring them up. I
personally would like to see EAP be used in a wide variety of access schemes
(i.e. PPP, SOCKS, IPSEC, Voice/IP, etc).

PatC
References: