Re: [Emu] Questions on draft-ietf-emu-eap-gpsk-02.txt

["Charles Clancy" <clancy at cs.umd.edu>]

On Thu, January 18, 2007 3:39 pm, Victor Fajardo wrote:
> Hi Tom/Hannes,
>
> I just have a couple of questions/comments regarding
> draft-ietf-emu-eap-gpsk-02.txt:
>
> o  In the terminology section, the last sentence of SEC_X(Y) definition
> is "SEC_X(Y) = Y|MAC_X(Y)". Maybe it should be "SEC_X(Y) = Y ||
> MAC_X(Y)" instead.

Yes.


> o  In Sec 8., 3rd paragraph:
>
>  "GPSK-1 contains no MAC protection, so provided it properly parses, it
>   MUST be accepted by the client. If the EAP client decides the
>   ID_Server is that of a AAA server to which it does not wish to
>   authenticate, the EAP client should respond with an EAP-NACK."
>
> Should this also provision for the case where the client is unable to
> support any of the ciphers in CSuite_List of GPSK-1 ? In such a case
> is it proper for the client to just send an EAP-NACK ?

There is a mandatory-to-implement cipher, so this should never happen.

> o  In Sec 8., 4th paragraph:
>
>   "For GPSK-2, if ID_Client is for an unknown user, the EAP server MUST
>    send either a "PSK Not Found" GPSK-Fail message, or an
>    "Authentication Failure" GPSK-Fail, depending on its policy, and
>    discard the received packet.  If the MAC validation fails, the server
>    MUST transmit a GPSK-Fail message specifying "Authentication
>    Failure". and discard the received packet.  If the RAND_Server or
>    CSuite_List field in GPSK-2 does not match the values in GPSK-1, the
>    server MUST silently discard the packet.  If server policy determines
>    the client is not authorized and the MAC is correct, the server MUST
>    transmit a GPSK-Protected-Fail message indicating "Authorization
>    Failure" and discard the received packet."
>
> In the case of "Authentication Failure" where the user is unknown or MAC
> is not correct maybe EAP_FAILURE is better (???) rather than GPSK-Fail
> since the failure is severe enough to warrant a method failure ?

See the paragraph immediately after the one you quoted:

   A client receiving a GPSK-Fail or GPSK-Protected-Fail message in
   response to a GPSK-2 message MUST either transmit an EAP-Failure
   message and end the session, or retry transmission of GPSK-2,
   attempting to correct whatever failure occured.  If MAC validation on
   a GPSK-Protected-Fail packet fails, then the received packet MUST be
   silently discarded.

The client has the option to send an EAP Failure to end the session and
try another EAP type, or retry EAP-GPSK.

> Should the CSuite_List in GPSK-2 be equivalent to CSuite_List in GPSK-1 ?
> Maybe I have the wrong impression but I thought the idea is auth sends
> a CSuite_List to peer and peer selects a supported CSuite denoted by
> CSuite_Sel. If this is the case we may not need CSuite_List in GPSK-2.
> Also, if CSuite_Sel does not match any value in CSuite_List in GPSK-1
> then auth can send GPSK-Fail.

The reason for sending CSuite_List in GPSK-2 is to authenticate it. 
GPSK-1 has no MAC protection, while GPSK-2 does.  This way the server
knows that the CSuite_List sent in GPSK-1 wasn't altered in transit, which
allows it to detect downgrade attacks.

> o  In Sec 8, 5th paragraph:
>
>   "A client receiving a GPSK-Fail or GPSK-Protected-Fail message in
>    response to a GPSK-2 message MUST either transmit an EAP-Failure
>    message and end the session, ... "
>
> I'm probably missing something but is the client allowed to send
> EAP-Failure ?

I don't see anything in RFC 3748 saying a peer CANNOT send an EAP-Failure,
but perhaps it would be better for GPSK to respond with another
GPSK-Failure message, and then have the sever send the EAP-Failure.

--
t. charles clancy, ph.d.  <>  tcc at umd.edu  <>  www.cs.umd.edu/~clancy

_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu