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

[Jari Arkko (jari.arkko]

Thanks for your prompt corrections! Your answers seem
OK to me, inline discussion for the few non-obvious cases:

>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?
>  
>
I think you should state that you negotiate the encryption algorithm
but not the integrity algorithm.

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

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

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

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

--Jari