eap Mailing List: expert review of EAP-SAKE

[Jari Arkko (jari.arkko]

Michaela et al,

Your method seems in general ready to receive its type code
allocation, but due to few omissions and some overlap
with existing RFCs the allocation is denied until these errors
are corrected. The corrections seems easy to do, however,
and some suggestions are given below. I hope you can submit
a new draft revision so that we can make a quick re-review.
I also had a few question marks, which may deserve
discussion. And as always, EAP WG list discussion may
bring up new issues and/or provide some information
on old ones.

>Justification
>-------------
>
>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?
>  
>
Yes.

>1b. Security claims. Are the claimed and not claimed
>properties listed?
>  
>
Almost, but not fully. Here are the deviations that I found:

   Replay protection is achieved via the Session ID field and the MIC
   present in each EAP packet. The Session ID MUST be generated anew by
   the Server for each EAP session. Session Ids also aid in
   identification of possible multiple EAP sessions between a Peer and
   the Server. It prevents replay between sessions.

Given that Session IDs are only 8 bits, their use as the
sole mechanism for replay protection seems weak. (But I think
you meant that the session id and the nonces together form
a replay protection mechanism; an earlier message cannot be
replayed because it used a different nonce than the one the
server used on this new session, even if the session ids happen
to collide.) Please clarify.

   Note that EAP.Response/SAKE/Auth-Reject and
   EAP.Failure messages cannot be signed in cases where there is an
   authentication failure, indicating that the Server and Peer do not
   agree on a common key.

It seems that EAP.Failure can not be protected in any case
with EAP-SAKE (or with any other method, really). Please
clarify.

RFC 3748 defines protected ciphersuite negotiation as follows:

   Protected ciphersuite negotiation
      This refers to the ability of an EAP method to negotiate the
      ciphersuite used to protect the EAP conversation, as well as to
      integrity protect the negotiation.  It does not refer to the
      ability to negotiate the ciphersuite used to protect data.

However, EAP-SAKE does not appear to provide the
negotiation of integrity protection algorithms or KDFs.
This should be noted in the security considerations.

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

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

>1e. 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.]
>  
>
Yes.

>2. Compliance with EAP packet formats
>
>2a. Does the method comply with the packet formats
>defined in Section 4 of RFC 3748?
>  
>
Yes. However,  Section 3.3.2. appears to define an alternate
and incomplete format to be used for Vendor-Specific variant
of this method (?). Is this an error in the specification, or a real
attempt to document both the SAKE version with a real type
code and the version without? Please clarify.

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

>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?
>  
>
No. Section 3.2.9. appears to be inconsistent with
RFC 3748, Section 4.3 and RFC 4137; retransmission
is in some cases handled by the authenticator,
not the server. Suggested remedy is simply referring
to RFC 3748 rather than trying to repeat the
guidance in this document.

Section 3.2.11 timeout explanation would probably
also benefit from referring to RFC 3748.

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

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

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

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

>4. Compliance with IANA requirements
>
>4a. Does the method comply with EAP-based IANA requirements
>redefined 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?
>  
>
Yes. Only a type number is needed, and the expert review
process is being used to request an allocation.

>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)?
>  
>
Yes. (But see other comments for a suggestion on adding
some information to Section 4.)

>5. Compliance with the EAP Key Management Framework
>
>5a. Description of key hierarchy. Is the key hierarchy
>documented?  Does the specification describe how the
>MSK and EMSK are calculated?  Are the MSK and EMSK 
>cryptogprahically independent? 
>  
>
Yes.

But not that Section 3.2.5 discusses the derivation of AAA-key
and defines AAA-Key as being equivalent to MSK. While this
is true, it would be useful to simply leave this definition
to eap-keying and not repeat it here. Additional definitions
in this document might also compromise the ability to
evolve the EAP keying hierarchy in the future.

>5b.  Does the specification describe how the Peer-ID and
>Server-ID are determined (if supported)?
>  
>
Yes.

>5c.  Does the specification define the Method-ID? 
>  
>

No. Please add a definition according to eap-keying.

Other:

The following comments have been provided in the interest
of letting the authors know other observed issues within
the document. They are not a part of the expert review, nor
do they represent a complete review of the other aspects
of the document, or even a RFC 3932 individual submission
review.

Reference [NAI] RFC number is 4282.

I found the following statement confusing:

   The existence of two MIC attributes in EAP-SAKE instead of one is an
   implementation choice, since the way the MICs are computed is
   different for the Peer and the Server.

Presumably, you have two attributes MIC_S and
MIC_P, but they never appear in the same message.

   packets is described in [EAP].The user ID (e.g. NAI) should be

Replace s/[.]The/. The/

Section 4 lacks a specification of IANA rules to be followed when
new allocations in the newly defined spaces are requested.
Please see draft-narten-iana-considerations-rfc2434bis-04.txt
for guidance.

Finally, idnits from tools.ietf.org reveals the following:

idnits 1.90 

tmp/draft-vanderveen-eap-sake-00.txt:

tmp/draft-vanderveen-eap-sake-00.txt(43): Line is too long: the offending 
characters are 'E).'
tmp/draft-vanderveen-eap-sake-00.txt(198): Line is too long: the offending 
characters are 'n and'
tmp/draft-vanderveen-eap-sake-00.txt(702): Line has weird spacing: '... Server  
 devi...'
tmp/draft-vanderveen-eap-sake-00.txt(704): Line has weird spacing: '... Server  
 devi...'
tmp/draft-vanderveen-eap-sake-00.txt(753): Line is too long: the offending 
characters are 'A1]):'
tmp/draft-vanderveen-eap-sake-00.txt(754): Line is too long: the offending 
characters are ','


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
    
    Checking conformance with RFC 3978/3979 boilerplate...

    the boilerplate looks good.

    No nits found.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  * The document seems to lack a 1id_guidelines paragraph about 6 months
    document validity -- however, there's a paragraph with a matching beginning.
    Boilerplate error?

    1id_guidelines paragraph 2 text:
    "Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress.""
  
    ... text found in draft:
    "Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time. It is inappropriate to use Internet-Drafts as reference
    material or cite them other than as "work in progress".")
................^


  - The page length should not exceed 58 lines per page, but there was 1
    longer page, the longest (page 41) being 59 lines
  - It seems as if not all pages are separated by form feeds - found 0 form
    feeds but 41 pages

  Miscellaneous warnings:
  - The document seems to use RFC 2119 keywords, but does not seem to
    contain the recommended RFC 2119 boilerplate

--Jari