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
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|