Subject: RE: No PPPEXT meeting at London IETF

From: [email-masked]
Date: Fri, 15 Jun 2001 16:09:32 +0300

> > The operation of USIM-Authentication-Reject and
> > USIM-GSM-Authentication-Reject versus EAP Nak isn't clear 
> to me.  What
> > do you expect the authenticator to do with these messages?  
> What does
> > the authenticatee do if it doesn't support this EAP 
> extension at all?
> 
> EAK Nak is sent to indicate that the peer does not support 
> the required
> authentication type. However, it isn't a general purpose 
> error mechanism,
> so it can't be used to say much more than that. In this 
> particular usage,
> distinct Reject message types are used, presumably to provide 
> more detail
> on the reasons why the peer cannot comply. I'm not sure that 
> they provide
> more information than a Nak does in this particular instance,
> though. Given that the authenticator knows what it was trying 
> to do, and
> knows that the peer couldn't do it (a Nak tells you that), what more
> information do these sub-types provide? 

Nak would tell the authenticator that the peer doesn't
support the EAP/AKA authentication type. GSM-Authentication-
Reject would tell the authenticator that the peer supports
the EAP/AKA authentication type, but it does not
accept the GSM backward compatibility version of EAP/AKA.
So the peer would like to use EAP/AKA with UMTS authentication
(but the authenticator isn't likely to be able to do that
because it tried GSM authentication in the first place).

This is not a big issue for us -- the information won't probably
be very useful for the authenticator anyway -- and we are happy 
to revise the draft to use Nak or some new RFC2284bis mechanism 
instead, if you feel that would be a better way to do it.

Regards,
Henry