Subject: [Emu] EAP-GPSK comments

From: Jouni Malinen <[email-masked]>
Date: Sat, 10 Jun 2006 21:26:29 -0700

draft-clancy-emu-eap-shared-secret-00.txt

KDFData:

What defines the arbitrary data (KDFData_Client and KDFData_Server)
that is to be included in the KDF? What is this used for? Chapter 7.4
defines a mechanism for server and peer to send "Extra KDF Data" to
allow binding data into the key derivation process. However, that
looks like any data could be sent and the server/peer would just
include it as a seed for KDF. Wouldn't this data need to be specified
somehow and used for something else than just an arbitrary seeding
material (e.g., export an identity or whatever else could be bound
here). The current draft does not seem to describe clearly how this is
to be used.

7.4: "If multiple entries are specified in a single PD_Payload with
PData/Specifier 3, then the first field must be used."
Is there any case where there would be more than one such entry?
Shouldn't that be just specified as an invalid message (MUST silently
ignore the packet?) instead of ignoring the extra entries that should
not have been there in the first place.

Chapter 4 seems to concatenate KDFData_Client and KDFData_Server into
the generic MSK and EMSK derivation. However, the cipher suite
specific derivation (6.1.3 and 6.2.3) does not. Was that on purpose?

ID Server/Client in key derivation:

Variable length ID_Server and ID_Client are concatenated in MK and
KDF_out derivation. This means that there is no explicitly specified
boundary between these fields and different values can produce same
keys (e.g., 'a || bc' and 'ab || c' would produce same keys). Should
ID_Server/Client length be prefixed as 16-bit value before the ID
value to make Server/Client ID boundary explicit? Alternatively 0x00
could be used as a delimiter (assuming it is not allowed in either ID
string).

Failure reporting:

What is the server/peer to do when something fails? For example, what
if GPSK-1 does not include a supported ciphersuite. What would peer
send in response? There does not seem to be an error message defined
for this purpose. Similar comments applies to other messages, i.e.,
behavior for error cases should be defined.

GKDF-X(Y, Z) definition (Chap. 5):

s%n = int( X / size ) + 1%n = int( (X + size - 1) / size)%
 (previous version would have one extra operation if X mod size = 0)

Need to define how many octets are used for i and X in input to MAC_Y.
Is this two octets in network byte order?

Input to Integrity MAC (6.1.2 and 6.2.2):

SEC_SK is the definition of how plaintext + MAC are concatenated, so
it does not look like the correct input for MAC. Should "Value of
SEC_SK in message GPSK-#" be replaced with "Payload of message
GPSK-#"? Based on other parts of the draft, it looks like this input
should be the data following OP-Code in the message.

Protected result reporting:

7.4 has following paragraph:

   Definition of the protected results indiciation field is outside the
   scope of this document.  It could be used to indicate the success or
   failure of both authentication and authorization in a secure way.

Why is this outside the scope of this document? How can 8.2 then claim:

   EAP-GPSK provides protected result indications based on information
   exchanged inside the protected data payloads.

Protected result indication sounds like a relatively simple addition
and I would prefer to see it included in the specification that
defined the new EAP method (i.e., in this document). That way, it
could be made mandatory and there would be no need for having to
handle backwards compatibility cases and allow sessions without
protected result indication in order to interoperate with many(most?)
implementations (which seems to be the case with, e.g., EAP-SIM and
EAP-AKA that leave this optional).

8.12 Channel Binding
"Channel binding is accomplished through the protected data blocks"

This draft does not specify exact mechanism for channel binding. Is
this claim valid without such specification? If nothing else,
s/is/can be/ could be considered here.

Minor comments/typos:

1:

Efficiency: s/allow for/allows for/
   (restriction ... allow_s_ for)

"Well suited for any type of device"
Hmm.. I would assume that there are many embedded devices that do not
have enough resources for running AES or SHA256, never mind
EAP-GPSK.. ;-)

2:

"CSuite_List" title missing before variable definition "An octet array
listing available ciphersuites (variable length)"

ID_Server: s/blog/blob/

3:

s/consists two/consists of two/

In GPSK-1, ...
s/peer sends its identity ID_Server/server sends its identity ID_Server/

5:

"The Code field in Figure 3 uniquely identifies a ciphersuite"
There is no Code field in Figure 3.. s%Code%CSuite/Specified% (?)

Is the following paragraph valid? 7.2 seems to indicate that
ciphersuites are always encoded as 6-octet arrays regardless of
whether they are vendir-specific or not.

   If Code=254 is used, a vendor-specific ciphersuite is encoded.  In
   this case, the following six octets identify the ciphersuite.  The
   first three octets are the vendor-specific OID, and the last three
   octets are vendor assigned.

7.2: s/indiciates/indicates/

7.3:
  s/256-bit RAND_Server/32-octet RAND_Server/ in Figure 7 (GPSK-1)
     (to be consistent with other figures)
  s/PD_Payload_1/PD_Payload_2/ in Figure 9 (GPSK-3)

7.4: s/indiciation/indication/

-- 
Jouni Malinen                                            PGP id EFC895FA

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 11 Jun 2006 14:17:28 +0200

Hi Jouni,

thanks for the detailed comments. Please find my response inline:

> here). The current draft does not seem to describe clearly how this is

The idea was that you would bind some data that is being exchanged 
between the peer and the server to the keys by including them into the 
key derivation function.

I never saw this functionality being useful but some design team members 
liked it. It was added very late in the draft writing process. Hence, I 
guess there are some loose ends.

I personally wouldn't mind removing it again. I am missing the uses cases.

> specific derivation (6.1.3 and 6.2.3) does not. Was that on purpose?

This question is related to the previous one.

The reason for not including the KDFDATA into all KDFs is that we need 
the keys before the KDFDATA is exchanged.

Added an issue for this aspect:
http://www.tschofenig.com:8080/eap-gpsk/issue3

> could be used as a delimiter (assuming it is not allowed in either ID
Do you see an attack if we don't use a delimiter?

Added an issue:
http://www.tschofenig.com:8080/eap-gpsk/issue4

> behavior for error cases should be defined.

There is a mandatory to implement ciphersuite (i.e., Ciphersuite 1) and 
hence this case cannot happen.

Do you have other failure cases in mind?

> Is this two octets in network byte order?

I am not so sure to what text you are referring.

> should be the data following OP-Code in the message.

We could make the definition of SEC more clear, namely:

"
    SEC_X(Y):

       SEC is a function that provides integrity protection based on the 
chosen ciphersuite. The function SEC uses the algorithm defined by the 
selected ciphersuite and applies it to the message content Y with key X. 
As an output the message returns Y concatenated with MAC_X(Y).
"

SEC is used in the protocol in message 2,3 and 4.

Here is message 2:

    GPSK-2:

       SEC_SK(ID_Client, ID_Server, RAND_Client, RAND_Server,
       CSuite_List, CSuite_Sel [, ENC_PK(PD_Payload_1), ... ] )

Regarding the text in 6.2.2:

  The following instantiation is used: AES-128-CMAC(SK, Input) denotes
    the MAC of Input under the key SK.

    where Input refers to the following content:
    o  Value of SEC_SK in message GPSK-2
    o  Value of SEC_SK in message GPSK-3
    o  Value of SEC_SK in message GPSK-4

This would now produce

ID_Client, ID_Server, RAND_Client, RAND_Server, CSuite_List, CSuite_Sel 
[, ENC_PK(PD_Payload_1), ... ] || AES-128-CMAC(SK,
ID_Client, ID_Server, RAND_Client, RAND_Server, CSuite_List, CSuite_Sel 
[, ENC_PK(PD_Payload_1), ... ] )

We could also write "... input should be the data following OP-Code in 
the message." It might be easier.

Do I miss the issue here?

> EAP-AKA that leave this optional).

I agree with you that we should add the protected result indication to 
the document.

Added an issue to the issue tracerk:
http://www.tschofenig.com:8080/eap-gpsk/issue1

> s/is/can be/ could be considered here.

We discussed two aspects:

* what channel binding mechanism should we use
(given the non-finalized discussions about this subject)

* where should we put it
(into this document or into a separate one)

I remember that we haven't reached a conclusion.

I think we should fix the text in Section 8.12 based on the outcome of 
our decision how to treat this subject.

I changed the text to:

"
This document enables the ability to exchange channel binding 
information. It does not, however, define the encoding of channel 
binding information in the document.
"

Added an issue:
http://www.tschofenig.com:8080/eap-gpsk/issue2

> have enough resources for running AES or SHA256, never mind

... that also run EAP.

> listing available ciphersuites (variable length)"

fixed.

> ID_Server: s/blog/blob/

:-)

> s/consists two/consists of two/
fixed.

> s/peer sends its identity ID_Server/server sends its identity ID_Server/
fixed.

> There is no Code field in Figure 3.. s%Code%CSuite/Specified% (?)

fixed.

>    octets are vendor assigned.

fixed.

> 7.2: s/indiciates/indicates/
fixed.

>   s/PD_Payload_1/PD_Payload_2/ in Figure 9 (GPSK-3)
fixed.

> 7.4: s/indiciation/indication/

Thanks for your review. Please find the updated draft at:
http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 11 Jun 2006 14:27:26 +0200

Here is a forward from the EMU DT mailing list where I mentioned that we 
did a formal analysis for EAP-GPSK.
As we update the protocol I will also reapply it again.

Ciao
Hannes

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im 
Auftrag von Tschofenig, Hannes
Gesendet: Freitag, 26. Mai 2006 11:21
An: [email-masked]
Betreff: [Emudt] Formal Verification of EAP-GPSK

Hi all,

to verify that we did not miss a severe (and potentially obvious)
security bug we ran the EAP-GPSK protocol against the AVISPA tools. The
tool could not spot problems with the protocol. (Note that does not mean
that it is correct.)

The HLPSL file can be found here:
http://www.tschofenig.com/TEMP/EMU/gpsk-Input.hlpsl

The language is similar to the one used in CASPER.
The security goal that was specified was authentication with the
Dolev-Yao intruder model being used.

More info about AVISPA can be found here:
http://www.avispa-project.org/

Some useful documents are:

* The High Level Protocol Specification Language
http://www.avispa-project.org/delivs/2.1/d2-1.pdf

* The Intermediate Format
http://www.avispa-project.org/delivs/2.3/d2-3.pdf

* HLPSL Tutorial
http://www.avispa-project.org/package/tutorial.pdf

* User Manual	
http://www.avispa-project.org/package/user-manual.pdf

Ciao
Hannes

---

From: Jouni Malinen <[email-masked]>
Date: Sun, 11 Jun 2006 09:34:28 -0700

On Sun, Jun 11, 2006 at 02:17:28PM +0200, Hannes Tschofenig wrote:

> >boundary between these fields

> http://www.tschofenig.com:8080/eap-gpsk/issue4

I did not look for a concrete attack, but I've seen this kind of
explicit field delimiters being added as a fix to number of this kind of
constructions and since this does not really add much extra cost in
processing, I would add one here, too.

> >if GPSK-1 does not include a supported ciphersuite.
>

Yes, I just listed the first one. If PSK does not match, server will
find an incorrect MAC in GPSK-2. What should it do? Just send
EAP-Failure? This is related to how protected result reporting is
implemented. In perfect world, there would be no other error cases, but
implementation error or an attacker could trigger some other failure
cases in GPSK-3 or GPSK-4. I did not find clear instructions on what the
implementation should do in such a case.

Now I just had to assume that client will drop these silently and server
will send EAP-Failure. If protected result protection will be added,
that change could also cover a mechanism for reporting any error in the
messages (though, error reports for GPSK-1 and GPSK-2 may not really be
protected since a shared key is not yet available).

> I am not so sure to what text you are referring.

This is in GKDF-X(Y, Z) definition of chapter 5 (Ciphersuites):

   GKDF-X (Y, Z)
   {
       n = int( X / size ) + 1; /* determine number of
                                       output blocks */
       M_0 = "";
       result = "";

       for i=1 to n {
           M_i = MAC_Y (M_{i-1} || Z || i || X);
           result = result || M_i;
       }

       return truncate (result; X)
   }

The fir part is for determining n. If X=16 and size=16,
n = int(16/16)+1 = 2 even though only one MAC_Y operation would have
been needed (and n = int(16 + 16 - 1) / 16 = 1). This is just a small
rounding off-by-one cleanup.

The more important change is in adding explicit definition of how i and
X are represented in input to MAC_Y in MAC_Y(M_{i-1} || Z || i || X)
construction. This needs added text to specify that i and X are used as
16-bit values in network byte order (assuming that is the intent here; I
used that assumption while implementing this since 8-bit X might not
have been long enough to cover all needs and 16-bit values seemed large
enough for this protocol).

> As an output the message returns Y concatenated with MAC_X(Y).

This is fine in itself, but..

>    o  Value of SEC_SK in message GPSK-2

This SEC_SK cannot be 'Input'.. Input would be Y in the SEC_X(Y)
definition, i.e., this Input is being passed into SEC function as Y..

> the message." It might be easier.

Yes.

> Do I miss the issue here?

Maybe. My main point was that SEC is a defined function and it does not
make sense to pass a function as an Input to AES-128-CMAC..

> http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/

Thanks. The changes looked fine ot me.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 11 Jun 2006 21:30:41 +0200

Hi Jouni,

> processing, I would add one here, too.

I am not sure I have seen this type of construction. Maybe I just forgot 
it.

Wouldn't you then have to add a delimiter for each concatenation symbol?

> protected since a shared key is not yet available).

Let me check what other EAP methods do.
I created an issue:
http://www.tschofenig.com:8080/eap-gpsk/issue5

> enough for this protocol).

Sounds reasonable to me.

> make sense to pass a function as an Input to AES-128-CMAC..
I don't think we pass a function to AES-128-CMAC. We just use the term 
SEC as a placeholder for the specific function that is later 
instantiated Y | MAC_X(Y). This is just an editorial aspect to keep the 
protocol description in Section 3 easier to read.

Ciao
Hannes

---

From: Jouni Malinen <[email-masked]>
Date: Sun, 11 Jun 2006 13:16:15 -0700

On Sun, Jun 11, 2006 at 09:30:41PM +0200, Hannes Tschofenig wrote:
> >>>KDF_out derivation.

> Wouldn't you then have to add a delimiter for each concatenation symbol?

As far as I can tell, only the cases where a variable length data is
used in a way that there is no clear boundary between two fields (e.g.,
two variable length fields concatenated together) would need this.
Adding 16-bit length field before the variable length ID_Server and
ID_Client would resolve this by making it explicit where the boundary
between ID_Client and ID_Server is.

---

From: Jouni Malinen <[email-masked]>
Date: Sun, 11 Jun 2006 14:01:43 -0700

On Sun, Jun 11, 2006 at 02:57:02PM -0400, Charles Clancy wrote:

> Thanks for your comments.  This is quite obviously a -00 document.  Many 
> of the inconsistencies you've pointed out are editorial, and certainly 
> not intentional.  We redesigned large parts of the protocol a couple 
> times, and unfortunately there are artifacts of previous designs throughout.

For -00 version, this was in quite good state. I was able to implement a
functional server and peer without any major problems and the number of
places needing "liberal interpretations" of the text was very small.

> We defined the format for "protected results indication" as out of 
> scope, mostly to get -00 out.  If the WG wants to define it in the 
> draft, then that's fine with me.  However, it might be useful to define 
> it in a seperate document, since like channel bindings, it could apply 
> to any method that supports a protected data exchange.

As long as it is available at the same time as EAP-GPSK would be taken
into use, I don't care that much whether it is included in the same
document or not. However, I would like to avoid need for
mandatory/optional selection and interoprability issues with some
implementations implementing this or not. Making it mandatory for all
cases (or not implement it at all, if that is preferred) would make
implementations simpler.

> We definitely need to add some specific text on what to do if MACs fail. 
>  I imagine the server would send an EAP-Failure if it occured after 
> packet 2, and others would be silently dropped.

One option would be to add a GPSK-ERROR opcode that would be used to
information peer of the error. In case the keys have already been
derived, this could be used as a protected result indication for the
failure case. Peer would reply with GPSK-ERROR and server would finish
the negotiation with EAP-Failure.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 11 Jun 2006 23:37:56 +0200

Hi Jouni,

~snip~
> places needing "liberal interpretations" of the text was very small.

Great. How long did it take you to get something implemented?
Will the code be made available?

Ciao
Hannes

---

From: Charles Clancy <[email-masked]>
Date: Sun, 11 Jun 2006 14:57:02 -0400

Jouni,

Sections 6.1.3 and 6.2.3 are definitely in error, and should include the 
KDFData fields.

Adding length fields to ID_Server and ID_Client in the KDF can't hurt. 
Not doing so won't introduce any practical attacks, but it would 
strenghten the binding between identity and key.

-- 
Dr. Charles Clancy, Research Scientist
Laboratory for Telecommunications Sciences
[email-masked]

---

From: Jouni Malinen <[email-masked]>
Date: Sun, 11 Jun 2006 16:08:25 -0700

> Great. How long did it take you to get something implemented?

Maybe a total of eight or so hours which includes reading the draft and
writing the review comments. Implementation itself with quick tests took
only couple of hours. Though, I had already implemented EAP-PSK/PAX/SAKE
before and that certainly helped here since I had all the EAP framework
and crypto routines available.

> Will the code be made available?

Server side is included in hostapd (integrated EAP server) and peer in
wpa_supplicant. The current development branch snapshot includes the
implementation (http://hostap.epitest.fi/releases/snapshots/). For
testing, I'm using hostapd as a RADIUS server with EAP-GPSK server and
eapol_test (test tool from wpa_supplicant) as a EAP-GPSK peer and IEEE
802.1X authenticator/RADIUS client. EAP-GPSK parts are in
hostapd/eap_gpsk.c and wpa_supplicant/eap_gpsk*.[ch].

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 11 Jun 2006 18:15:14 -0700

>find an incorrect MAC in GPSK-2. What should it do? Just send EAP-Failure?

I would recommend silent discard for packets with MAC failures, since that 
is most resilient against forgery.  Otherwise, an attacker only needs to 
correctly guess the Identifier (not hard, there are only 256 choices) and it 
can abort the EAP conversation.

>This is related to how protected result reporting is
>implemented.

If the PSK has not been  correctly configured, then it makes little sense to 
attempt to send a protected result indication, since the MAC on that message 
would also fail to verify.

---

From: Charles Clancy <[email-masked]>
Date: Sun, 11 Jun 2006 22:29:48 -0400

Bernard Aboba wrote:
 >> EAP-Failure?
 > I would recommend silent discard for packets with MAC failures, since
 > that is most resilient against forgery.  Otherwise, an attacker only
 > needs to correctly guess the Identifier (not hard, there are only 256
 > choices) and it can abort the EAP conversation.

If the EAP Server silently drops EAP-Response/GPSK-2, then how would the 
client know the PSK is incorrect?  Would the conversation just time out?

Perhaps we should add a "MAC Failed" message as Jouni suggested? 
Sending it would leave the server state unchanged.

--
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 11 Jun 2006 20:11:09 -0700

Yes.

>Perhaps we should add a "MAC Failed" message as Jouni suggested? Sending it 
>would leave the server state unchanged.

What is the peer supposed to do with this?  If it isn't authenticated, then 
an attacker can forge it and cause the peer to abort the conversation.  If 
it is authenticated, then if the PSK is incorrectly configured, the peer 
will drop it.   Since an attacker can send a forged packet and to cause this 
message to be sent, about all the peer could do with it is log it and leave 
its own state unchanged.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 11 Jun 2006 20:58:41 -0700

At 07:29 PM 6/11/2006, Charles Clancy wrote:
>If the EAP Server silently drops EAP-Response/GPSK-2, then how would 
>the client know the PSK is incorrect?  Would the conversation just time out?
>

I am not a fan of MAC failed messages, to say the least.  Those would 
allow an adversary to start guessing the PSK and have the guesses 
deterministically validated by the server.  I would however send a 
generic failure message, if it helps.  I also agree with Bernard's 
take on this.

regards,
Lakshminath

---

From: Jouni Malinen <[email-masked]>
Date: Sun, 11 Jun 2006 22:52:46 -0700

> generic failure message, if it helps.  I also agree with Bernard's 

Based on the number of questions I see from end users wanting to know
what exactly went wrong and how to diagnose authentication failures, it
would be nice if there were a better mechanism for figuring out that PSK
could have been wrong that just waiting for a timeout. Unfortunately, in
the case of GPSK-2, there are no shared keys to authenticate this
information. Any errors for GPSK-3 or 4 could be reported with a MAC.

Generic error message can be faked since the peer has no way of knowing
whether the server derived the same key as it did and would have to
ignore MAC failure in the error message. Server could send some kind of
error notification that the peer is free to ignore based on its security
policy. That would allow a faster reaction on the client side and at
least possibility of the peer implementation determining that the reason
for failed authentication was in server not liking something about
GPSK-2 instead of it being unclear whether the server even received
GPSK-2.

I don't want to open any security issues with this, but it would be nice
to provide something to make it easier to report somewhat meaningful
report to the user. Now, I can just report "possible PSK mismatch or
server unreachable" after a (potentially long) timeout if GPSK-2 with
incorrect MAC is silently ignored. Would there be any mechanism to make
this report more informational for the user?

---

From: Charles Clancy <[email-masked]>
Date: Mon, 12 Jun 2006 06:55:16 -0400

Bernard Aboba wrote:
> What is the peer supposed to do with this?  If it isn't authenticated, 
> then an attacker can forge it and cause the peer to abort the 
> conversation.  If it is authenticated, then if the PSK is incorrectly 
> configured, the peer will drop it.   Since an attacker can send a forged 
> packet and to cause this message to be sent, about all the peer could do 
> with it is log it and leave its own state unchanged.
> 

What sort of attacker are we trying to stop here?  A non-MitM, 
eavesdropping DoS attacker?  Certainly a MitM attacker can just drop all 
our packets.

If the MAC in GPSK-2 fails, the server can certainly send an 
authenticated response.  He has all the necessary information to compute 
the proper session keys.  The client jsut wouldn't be able to verify the 
MAC.

Do the following cases sound right according to normal EAP behavior?

Case 1: received one MAC-failed message with invalid MAC = PSK incorrect
Case 2: received two or more MAC-failed messages with differing invalid 
MAC = PSK incorrect, and being DoS'd

The timeout approach works too.  In that case, we can distinguish 
"invalid PSK" from "EAP Server unreachable".  If the EAP Server is 
unreachable, the client would never have received EAP-GPSK1.