Subject: [eap] methods and expert reviews

From: Jari Arkko <[email-masked]>
Date: Tue, 07 Jun 2005 12:36:54 +0300

Hello folks,

Just to keep you updated on what's going on with expert reviews
of methods: We have gotten a number of requests for expert reviews
and iana assignments. Expert reviews are focusing on making sure
RFC 3748 is followed. The template for such reviews is at
http://www.drizzle.com/~aboba/EAP/template.txt
We have gotten a number of volunteers to do such reviews,
see below. Thanks for the volunteers!

We hope to receive the reviews in two weeks, which should
give some time for discussion & revision before the next
I-D deadline, if necessary.

Other comments and opinions on methods are also welcome both
by these reviewers or other members of the WG on, e.g.,
the usefulness of the methods for a particular purpose, security
properties, what people feel like is something that they would
implement, etc.

EAP-PSK
<http://www.ietf.org/internet-drafts/draft-bersani-eap-psk-07.txt>
Reviewer: Jesse Walker

EAP-IKEv2
<http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-06.txt>
Reviewer: Pasi Eronen

EAP Double TLS
<http://www.ietf.org/internet-drafts/draft-badra-eap-double-tls-03.txt>
Reviewer: Hannes Tschofenig

EAP Smartcard Type
<http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-type-01.txt>
Reviewer: Glen Zorn

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: <[email-masked]>
Date: Mon, 13 Jun 2005 15:27:54 +0300

Hi,

Having read draft-tschofenig-eap-ikev2-06, I believe this 
document is not ready for expert review yet. It needs a 
substantial amount of work to make it a decent EAP method 
specification, and its compliance with RFC 3748 is best 
assessed once it has matured a bit more.

Some comments (not as RFC3748 expert reviewer, but an
ordinary reviewer):

- The description of the protocol is very confusing reading.
  In many cases, the document seems to pretend it is using IKEv2
  as an EAP method, or profiling IKEv2, but it's not: This is a
  new protocol that just happens to copy many aspects from IKEv2
  (which is mainly a good idea, of course).

  So talking about sending IKEv2 messages is plain wrong:
  in almost all cases, the messages are not a valid IKEv2 
  messages. Even when the message formats look similar, the 
  semantics of the payloads and exchanges are not.

  Sometimes this gets just plain silly: For instance, Section 4
  says "In particularly the following messages and payloads
  SHOULD not be sent Traffic Selector (TS) payloads...". So what
  exactly would be the "valid reasons in particular circumstances" 
  (from RFC2119 definition of "SHOULD") to ignore this item,
  and how should the other end process those payloads?

  My suggestion for rewriting the draft would be as follows:
  First, consider choosing a less confusing name for your
  protocol. Then describe whatever message exchanges you have 
  in correct terms: you're describing EAP-IKEv2 messages 
  (not IKEv2 messages) that contain EAP-IKEv2 payloads (which 
  may copy the details from IKEv2 payloads, but the semantics 
  often change slightly... and then you don't have to say that 
  "traffic selector payloads must not be included", because 
  there's no such payload type in EAP-IKEv2). Finally, when 
  you have described what the EAP-IKEv2 messages and payloads 
  mean, you can say that the syntax is the same as for similarly 
  named IKEv2 payloads (so you get to reuse the work done for IKEv2).

- While copying the cryptographic aspects from IKEv2 is a good
  idea, perhaps copying everything is not (e.g. the messages
  for fast reconnect could be called something else than
  a "CREATE_CHILD_SA exchange", since CHILD_SAs are not very
  meaningful in this context)

- Since this document does not defined a tunneled EAP method,
  I'd suggest deleting all mentions this feature of IKEv2 
  (or at least move the text talking about "if we supported 
  this feature, it would be done that way" to an Appendix).

- Section 6: "Currently five bits ... are defined": this
  section defines the meaning of only three bits. Strangely
  enough, two other bits are named ("S" and "F") but it
  is not described why they're named, or what they mean.

- Section 6: "Each fragment sent must subsequently be 
  acknowledged": how?

- Section 8: length of EAP-IKEv2's MSK and EMSK is at least 64
  octets: how do the parties decide how much longer than 64
  octets? (or if it's exactly 64 octets, say so)

- Section 9: The part starting with "To avoid this..." sounds
  fishy: what's the benefit of having two different options
  in this situation? 

- Section 10: What happens if the peer has forgotten the SA?
  (figures 8 and 9 assume the peer still has the SA, 
  since it can send messages having "SK{..}")

- Section 11.4: since we have payloads whose contents are not 
  described in this document, we need a normative reference
  to some document whey there are described. Otherwise,   
  an implementation can't process those contents in an
  interoperable fashion...

- Section 12 should include some text about identity privacy
  (especially when doing fast reconnect or authenticating both
  parties using shared secrets).

- Missing "IANA considerations" section.

Best regards,
Pasi

---

From: "Walker, Jesse" <[email-masked]>
Date: Wed, 15 Jun 2005 06:42:10 -0700

This is a follow up to my earlier review of EAP-PSK. There is one
suggested improvement that I made that does not work, so can itself be
improved upon.

> The first is to try to use AES in CBC-MAC mode, but for that we need a
> key; one idea for a key is the PSK:
> 
> 	IV := AES-128-CBC-MAC(PSK, M)
> 
> This is not ideal, however, because PSK would be used in two different
> ways --once for hashing and a second time for key derivation--and
multiple
> usages of a single key is almost always a bad idea. While reuse in
this
> case may appear benign on first glance, why should we bother with an
> approach that will require a tricky analysis to confirm that it is
indeed
> safe? A variant would be to use some "well-known" key as the CBC-MAC
key,
> although this key would always be block cipher dependent:
> 
> 	K := 00000000000000000000000000000000 (* AES dependent key! *)
> 	IV := AES-128-CBC-MAC(K, M)
>
> In either case, the "hashing" scheme relies on the assumption that a
block > cipher in CBC-MAC mode is a pseudo-random function, so the
resulting
> output should be collision resistant for each pair of identities and
> length (at least if we construct M properly). If you prefer, use OMAC1
> mode instead of CBC-MAC. Relying on CBC-MAC for hashing is an
egregious
> but probably effective hack.
>
> A second way to compute IV might be to Davies-Meyer hash M under
AES-128:
>
>	Partition M = M1 M2 ... Mn into 128 bit blocks
>	H := 00000000000000000000000000000000
>	for i = 1 to n do
>		H := AES-128-Encrypt(Mi, H) XOR H
>	IV := H
>

Yesterday while paging through the proceedings of EUROCRYPT 2005 from
last week, I ran across a gem of a paper by Black, Cochran, and
Shrimpton [1] that is relevant to this discussion. In it they prove that
we cannot get collision resistance out of a block cipher based hashing
construction cheaply; something like the Davies-Meyer construction is
the most efficient you can hope for. Since we need collision resistance
here, their result rules out my first suggestion, and leaves us with
only something like the second as viable.

I don't think this is a big deal for hashing the identities in IV,
because that calculation is done only once, during the configuration of
the long-lived keys. I suggested the same pair of algorithms again for
hashing RAND_S and RAND_P at the beginning of each session, and there
the expense is too great:

> Returning to the trust assumption, the peer has to assume that the
server
> will generate a different RAND_S on every instance of the protocol. We
> will see in the protocol analysis this is not a good
assumption--replay
> attacks are feasible against the peer--and indeed, it is unnecessary.
It
> is almost always a good idea to remove unnecessary assumptions when we
can.
> We could perhaps remove the trust assumption about RAND_S by again
hashing
> together RAND_S and RAND_P to obtain the RB value to use, e.g.:
> 
> 	RB := AES-128-CBC-MAC(0^128, RAND_S || RAND_P || 0^117 || 0x480)
> 
> using the CBC-MAC hashing method with a 0 key, or
> 
> 	H := 00000000000000000000000000000000
> 	H := AES-Encrypt-128(RAND_P, H) XOR H
> 	H := AES-Encrypt-128(RAND_S, H) XOR H
> 	RB := AES-Encrypt-128(0^117 || 0x480, H) XOR H
> 
> using Davies-Meyer hashing. Etc.

Davies-Meyer hashing is too expensive when done this way, because it
costs three key schedule initializations. However, since the CBC-MAC
hack won't work by the Black-Cochran-Shrimpton result, we either have to
forgo the function or else live with a performance penalty or else live
with only one of the RAND-x's as input to the session key derivation.

A computationally better alternative might be a different hack, e.g.:

	RB := AES-128-Encrypt(RAND_S, RAND_P) XOR RAND_P

This requires only one key schedule initialization, during session
initialization, which ought not be too onerous. This provides genuine
collision resistance (if the underlying block cipher is secure). This
does not mix the length into RB, but it is difficult to believe a prefix
attack on this construction is possible, because it hashes the minimum
amount of data (a single block) as it is.

References

[1] J. Black, M. Cochran, and T. Shrimpton, "On the Impossibility of
Highly-Efficient Blockcipher-Based Hash Functions," EUROCRYPT 2005, pp
526-541

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sat, 18 Jun 2005 17:15:29 +0200

hi all, 

here is a review of <draft-badra-eap-double-tls-03.txt>:

1. Does the method document its security properties
in sufficient manner, as required by Section 7.2
of RFC 3748?

1a. Mechanism. Is the mechanism explained?

the mechanism used eap-tls, draft-ietf-tls-sharedkeys and some additional "inner" mechanisms similar to peap or ttls (but seems to go beyond them). 
 
the security properties of the "inner" mechanisms are not well described (e.g., the usage of draft-urien-eap-smartcard or other authentication mechanisms such as kerberos). 

1b. Security claims. Are the claimed and not claimed
properties listed?

since the method introduces many optional parts it is difficult to illustrate the security properties in a single list (e.g., the draft name says "double-tls" but one option is the protocol is it to use it without the "double" part). as a consequence the security properties are entirely different. 

the aspect of cryptographic binding is not described. 

1c. Justifications for the claims? Is an explanation or
reference provided to each of the claims?

most of the security properties are described but this should be done in the context of the different protocol options. for example, what happens if you do not use pfs, identity protection and tunnel eap-md5 over eap-tls?  
explanations are given but they are applicable only to certain modes of operation. 

1d. Key strength. Is the key strength documented?

only a pointer to the tls-prf function is given. this is insufficient.

1e. Description of key hierarchy. Is the key hierarchy
documented?

section 3.4 mentions the key derivation. however, more information is required to see how the crypto-binding works, how the MSK is derived. the current text seems to focus on the tls key derivation. 

[Optional, at least for now: does it conform to EAP
keying framework?]

no. 

1f. Indication of vulnerabilities. Are the known vulnerabilities
documented?

[Note: it seems unreasonable to require the documentation
of unknown vulnerabilities :-) The "known" may of course be
"known to reviewer" or "known to author" or "known to the
community", but that appears to be best we can do.]

no vulnerabilities are mentioned. 
the need for the crypto-binding must be mentioned in order to prevent man-in-the-middle attacks. 

2. Compliance with EAP packet formats

2a. Does the method comply with the packet formats
defined in Section 4 of RFC 3748?

yes. 

3. Compliance with EAP behaviour

3a. Does the method comply with Success/Failure usage
as defined in Sections 2, 2.2, and 4.2?

yes, implicitly follows the same procedure as eap-tls 

3b. Does the method comply with sequence usage as defined
in Section 2.1 of RFC 3748?

yes. 

3c. Does the method comply with request/response processing
rules as defined in Section 4.1 of RFC 3748?

yes. 

3d. Does the method comply with retransmission rules
as defined in Section 4.3 of RFC 3748?

not mentioned although there might be some issues with regard to the inner authentication methods that require user input. 

3e. Does the method comply with the usage defined for
Identity, as defined in Section 5.1 of RFC 3748?

yes; 

the concept of temporal identities is used to provide user identity confidentiality. 
synchronization issues need to be addressed (i.e., what happens if the state is out-of-sync) but this does not seem to impact rfc 3748. 

3f. Does the method comply with the usage defined for
Notification, as defined in Section 5.2 of RFC 3748?

yes, implicitly mentioned with a reference to eap-tls

3g. Does the method comply with the usage defined for
Nak and Expanded-Nak as defined in Section 5.3 of RFC 3748?

not mentioned. 

3h. Does the method comply with the MIC usage requirements
from Sections 3.1, 7.5, and 7.8 of RFC 3748?

yes, implicitly since it follows eap-tls.

4. Compliance with IANA requirements

4a. Does the method comply with EAP-based IANA requirements
defined in Section 6 of RFC 3748? That is, if it requests
the allocation of new numbers in the EAP namespace [not
applicable if the numbers have already been allocated],
is the type of the document and process appropriate for the
desired action?

a request to iana to allocate a new eap type is indicated. 
inner methods might also require the creation of a registry
or is the eap-ttls namespace inherited?

4b. Does the method comply with other IANA requirements in
the IETF standards track RFCs? For instance, does the
method attempt to allocate TLS extensions (which would
only be possible for standards track RFCs)?

i am not sure whether the authors want this document become a standards track rfc. 

a few minor comments:
- the reference section needs to be split into normative and informative references. having (expired) drafts in the normative part of the reference section will be problematic. 
- the relationship of appendix a to the rest of the document is not clear.
- kerberos is mentioned at several places throughout the document. it is not described how kerberos should be used in the context of this method. 
- although the advantages of the eap method are advertised in the context of tunneling an eap method (or other authentication methods) over eap-tls eap-double-tls allows to skip the inner method. the relationship to other methods, such as peap, eap-ttls and eap-fast, is not clear. if the goal is user identity confidentiality for the eap peer and pfs then more efficient methods are available.

ciao
hannes

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Jari Arkko
> Gesendet: Dienstag, 7. Juni 2005 11:37
> An: [email-masked]
> Betreff: [eap] methods and expert reviews
> 
> 
> Hello folks,
> 
Reviewer: Pasi Eronen

EAP Double TLS

EAP Smartcard Type

---

From: Thomas Otto <[email-masked]>
Date: Fri, 24 Jun 2005 17:15:28 +0200

Comments on the review of EAP-PSK - third (=last) part

> Point (c). Neither Figure 3 nor the accompanying text spells out
> explicitly how message 4 is protected. Message 4 could be protected by
> either the AK (and an OMAC1) or by the TEK (used with EAX). 

The format of message 4 is  Flags||RAND_S||PCHANNEL_P_1 , 

with a 1-byte Flags field, 16 byte server random of message 1, and the 
PCHANNEL field. 

I assume that RAND_S is sent in plaintext. Since it is sent plain in 
message 4, and since it serves in this context only as a session identifier, 
an encryption makes IMHO no sense.

In section 3.3 of EAP-PSK, the format of PCHANNEL is explained. PCHANNEL 
contains three or four flags, in case of the mode (no extension, extension). 

* 2-bit R (result indication flag), 
* 1-bit E (extension flag)
* 5-bit Reserved
* variable length EXT (extension)

which are sent encrypted by the protected channel. A reference is given to
section 2.2.3, The Protected Channel. 

Thus, the format of message 4 is more detailed

Flags || RAND_S || Nonce || Tag || R || 0 || Reserved
                                  xxxxxxxxxxxxxxxxxxx

and, for the extended mode, 

Flags || RAND_S || Nonce || Tag || R || 1 || Reserved || EXT
                                  xxxxxxxxxxxxxxxxxxxxxxxxxx

where the "x" highlight the part to be encrypted.

Now, EAX mode keyed with the TEK encrypts the payload like
follows:

4 bytes  22 bytes  var.length L        16 bytes

                     R 0 Reserved *or* 
Nonce N  Header H    R 1 Reserved EXT   TEK
  |         |             |              |
  v         v             v              v 
+-------------------------------------------+
+              EAX                          +
+-------------------------------------------+
  |             |
  v             v 
ciphertext     Tag
payload     16 bytes
xxxxxxxxxx

In the
> latter case, we need to know which bits are encrypted and which merely
> forgery protected. 

R, 0, Reserved (,EXT)

So, we talk about 8 bits in standard mode and 8+|EXT| bits 
in the extended mode of operation. 

[snip]

> Here are a number of miscellaneous comments:
>
> It would be worth considering replacing OMAC1 by CMAC. NIST SP800-38B
> [2] defines CMAC as the "approved" CBC-MAC variant.
>

This leads to an analysis whether EAX must be replaced as a consequence.
The authors' argument to take EAX was that it strongly relies on OMAC 
(see, for instance, figure 2 and 3 in 
http://www.cs.ucdavis.edu/~rogaway/papers/eax.html).