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

From: Victor Fajardo <[email-masked]>
Date: Thu, 18 Jan 2007 15:39:53 -0500

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.

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 ?

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 ?

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.

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 ?

regards,
victor

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Charles Clancy" <[email-masked]>
Date: Mon, 22 Jan 2007 12:51:09 -0500 (EST)

> is "SEC_X(Y) = Y|MAC_X(Y)". Maybe it should be "SEC_X(Y) = Y ||

Yes.

> is it proper for the client to just send an EAP-NACK ?

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

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

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

> I'm probably missing something but is the client allowed to send

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.  <>  [email-masked]  <>  www.cs.umd.edu/~clancy

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 22 Jan 2007 19:34:39 -0800

>GPSK-Failure message, and then have the sever send the EAP-Failure.

RFC 3748 Section 4.1 says:

    The peer MUST send a Response packet in reply to a valid Request packet.

So an EAP peer cannot send an EAP-Failure in response to a Request.   If it 
were to do so, the authenticator would just retransmit the Request, since 
Section 4.1 says:

      The Request packet (Code field set to 1) is sent by the
      authenticator to the peer.  Each Request has a Type field which
      serves to indicate what is being requested.  Additional Request
      packets MUST be sent until a valid Response packet is received, an
      optional retry counter expires, or a lower layer failure
      indication is received.