[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.
> -----Original Message-----
> From: Gabriel Montenegro [mailto:gab@Eng.Sun.Com]
> Sent: Thursday, April 16, 1998 11:50 AM
> To: Shawn Mamros
> Cc: pcalhoun@eng.sun.com; 'ipsec@tis.com'
> Subject: Re: Radius authentication and client configuration
>
>
> > By placing policy/configuration setup in ISAKMP (between
> Phases 1 and 2)
> > under protection of the ISAKMP SA, Roy's proposal for an
> ISAKMP Configuration
> > Method addresses the security needs quite nicely. That's
> not to say that
> > one couldn't base the payload/exchange format on DIAMETER
> or whatever else
> > is already out there. But the ISAKMP SA only protects
> ISAKMP, and until the
> > IPSEC SAs are set up, ISAKMP may very well be all you can trust.
>
> Agree.
>
> It seems like the *cfg* and *xauth* drafts may just take
> existing payloads
> defined elsewhere to achieve their purposes. For example, xauth
> could just say: let's use EAP payloads (as I suggested
> in LA). EAP did start in ppp land, but has since been applied to
> (that is, its payloads have been reused in) SOCKS, RADIUS, DIAMETER.
>
> So yes, if a good payload exists, reuse it.
>
> -gabriel
>
Follow-Ups: