eap Mailing List: Re: expert review of EAP-SAKE

[M. Vanderveen (mvandervn]

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:jari.arkko [at] piuha.net]
Sent: Monday, April 10, 2006 3:37 AM


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

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

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.

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.

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

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.

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?

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

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

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

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

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.

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

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

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

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

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

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.

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

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

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:


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