Subject: [eap] expert review of EAP-SAKE

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Apr 2006 13:37:27 +0300

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

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "M. Vanderveen" <[email-masked]>
Date: Mon, 10 Apr 2006 16:02:24 -0700 (PDT)

Hello Jari
Thank you so much for leading this effort. All points raised are clear
and so will be addressed as such, see inline.

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Monday, April 10, 2006 3:37 AM

MCV>> Rephrase as: "Replay protection is achieved via the RAND_S and
RAND_P values, together with the Session ID field, which are included in
the calculation of the MIC present in each packet subsequent to the
EAP-SAKE/Challenge request packet."
--------------------------------------------

MCV>> "Note that EAP.Response/SAKE/Auth-Reject cannot be protected with
a MIC since an authentication failure indicates that the Server and Peer
do not agree on a common key." 
>>> If this still sounds like stating the obvious, I will remove this
sentence altogether.

-----------------------------------------------------

MCV>> True, the ciphersuite is negotiated for the protection of data
transported as part of the EAP method, not for MIC computation.
Therefore the security consideration will list "protected ciphersuite
negotiation" under the "not supported". Section 5.15, which talks about
negotiation attacks and how the ciphersuite used to protect data (e.g.
encryption algo) is securely negotiation, can I guess be removed to. Is
ciphersuite negotiation for data protection considered not a noteworthy
feature? It should be pretty clear from the message exchange that the
encryption algorithm is securely negotiatied (if needed at all), and so
is it worth writing a paragraph about it?

-----------------------------------------

MCV>> I was under the impression that all new methods should support
expanded types. The format in Section 3.3.2 is the Expanded Type format.
I guess since after this review a number will hopefully be allocated,
there will be no need for such a section and so I will remove it.
However for my own curiosity why does it appear incomplete? It ends on
the "subtype" field just like the original header format in the section
right above it (3.3.1). I felt that this format needs to be clearly
defined since there are no requirements in RFC 3748 about how the
"Vendor-Data" field should be arranged, and so just plugging in the rest
of the packet as specified in section 3.3.1 wouldn't work well (need an
extra byte, which is set to 0 as padding for word-alignment).

-------------------------------

MCV>> In that case how about not referring to any RFC, and removing that
section altogether. For example, the EAP-AKA RFC does not specifically
address retransmission.

MCV>> Ditto (remove the paragraph with the time-outs).

-----------------------------------

some information to Section 4.):

MCV>> This comment probably refers to the 2nd and 3rd requirement in 
Rfc2434bis, section 4.2. To satisfy 2) (info provided when requesting
new values), we will add the following (which follows closely the
counterpart of the EAP-AKA RFC):
" All requests for value assignment from the two number spaces
described in this memo require proper documentation, according to
the "Specification Required" policy described in [RFC2434]. Requests
must be specified in sufficient detail so that interoperability
between independent implementations is possible. Possible forms of
documentation include, but are not limited to, RFCs, the products of
another standards body (e.g., 3GPP), or permanently and readily
available vendor design notes."
To satisfy 3) (the review process associated with 2)), we will add the
following:
" All requests for value assignment from the two number spaces
described in this memo require IETF consensus".

MCV>> We will also classify the attributes into skippable and
non-skippable.

----------------------------

But not[e] that Section 3.2.5 discusses the derivation of AAA-key

MCV>> Will remove all references to the AAA-Key from section 3.2.5,
including the fact that this key is set to be the MSK.

----------------------------

No. Please add a definition according to eap-keying.
MCV>> Here it is: "The EAP-SAKE Method-Id is the
contents of the RAND_S field from the AT_RAND_S attribute,
followed by
the contents of the RAND_P field in the AT_RAND_P attribute."

--------------------------------------------
Other:

Presumably, you have two attributes MIC_S and
MIC_P, but they never appear in the same message.
MCV>> I added this sentence because of a question I got earlier about
why there are two MIC attributes instead of one (which can be added to
any message, as per specification). Since it seems confusing, I will
remove it altogether.

-------------------------------------------------
All nits will be fixed.

---------------------------------
How low will we go? Check out Yahoo! Messenger’s low  PC-to-Phone call rates.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 11 Apr 2006 07:06:58 +0300

Thanks for your prompt corrections! Your answers seem

>is it worth writing a paragraph about it?
I think you should state that you negotiate the encryption algorithm
but not the integrity algorithm.

Ok. I think I now understand what you meant. RFC 3748 wants
implementations to support expanded types, and that when type
code < 256 they need to be treated equivalently with the shorter
form. Perhaps you could say something about this in the introduction
for the section, and then fill in the values that did not seem obvious
to me on the first read:

- vendor-id = ietf
- vendor-type = the same as type in the previous section, except that
its four
  bytes long
- expand definition of pad into words (set zero on send, ignore on receipt)
- say that all the other fields are as in previous section

>section altogether. For example, the EAP-AKA RFC does not specifically
Ok.

>   available vendor design notes."
The first sentence would be enough -- all you need to do is to
use the 2434/2434bis keywords such as "Specification Required".
(And its up to you which keyword to use.)

EAP-AKA was a bit special because it gave 3GPP the right to
administer values.

>      the contents of the RAND_P field in the AT_RAND_P attribute."
Ok.

--Jari