Hi Bernard,
Thank for the review. Comments in line below:
On Dec 15, 2010, at 12:14 PM, Bernard Aboba wrote:
> There are two major issues remaining in this document.
>
> One issue is that in a number of places, the document appears to
> contradict IETF standards track documents.
>
> Examples:
>
> Section 3.1
>
> If the client requires the use of the Keying-Material Attribute
> for keying material delivery and it is not present in the Access-
> Accept or Access-Challenge message, the client MAY ignore the
> message in question and end the user session.
>
> [BA] Presumbly the MAY is included here for security reasons, such as
> preventing
> the client from accepting a downlevel key from a server from which it has
> previously received keying material described in this document, thus
> preventing
> spoofing in the event that the RADIUS shared secret (or MD5) is compromised.
> However, in such a situation the key material itself would be compromised,
> so that some sort of warning should probably be raised.
>
[Joe] How about the following:
"In environments where the the Keying-Material attribute is known to be
supported or in cases where the client wants to avoid roll-back attacks the
client MAY be configured to require the use of the Keying-Material Attribute.
If the client requires the use of the Keying-Material Attribute for keying
material delivery and it is not present in the Access-Accept or
Access-Challenge message, the client MAY ignore the message in question and end
the user session."
> My recommendation is that this be rewritten to state the considerations
> underlying the MAY, as well as recommended behavior in line with RFC 2865
> Section 5.26, which states:
>
> Clients which do not receive desired vendor-specific information
> SHOULD make an attempt to operate without it, although they may do
> so (and report they are doing so) in a degraded mode.
>
> RFC 2865 is written this way to prevent the creation of proprietary RADIUS
> implementations that require the presence of vendor-specific information.
>
> Section 3.3
>
> Any packet that contains an instance of the Message-
> Authentication-Code Attribute SHOULD NOT contain an instance of
> the Message-Authenticator Attribute [RFC3579].
>
> [BA] Since the Message-Authenticator Attribute is mandated by RFC 3579,
> this represents a contradiction. My recommendation would be to remove
> this sentence, and require that the key used in computing the
> Message-Authentication-Code be cryptographically independent of the
> RADIUS shared secret. That way both attributes can be included without
> damage.
>
[Joe] I think we can remove the sentence. The section states that if both are
present the Message-Authenticaiton-Code attribute is computed first, but there
may be ambiguity as to whether the message-authenticator attribute is included
in the calculation or not.I would think it would be, I'd like to try to get
some verification from implementers on this.
> Section 5
>
>It is RECOMMENDED in this memo that two new keys, a key encrypting
>key and a message authentication key, be shared by the RADIUS client
>and server. If implemented, these two keys MUST be different from
>each other and SHOULD NOT be based on a password. These two keys
>SHOULD be cryptographically independent of the RADIUS shared secret
>used in calculating the Response Authenticator [RFC2865], Request
>Authenticator [RFC2866] [RFC5176] and Message-Authenticator Attribute
>[RFC3579]; otherwise if the shared secret is broken, all is lost.
>
> [BA] I believe that cryptgraphic independence of the RADIUS shared secret
> needs to be a MUST, since the goal of this document is to provide security
> even in a situation where the RADIUS shared secret could be compromised.
>
[Joe] I think we can make the cryptographic separation from the RADIUS shared
secret a MUST.
> Another issue is that there are a number of fields for which "the content
> of this field is outside the scope of this document." The document
> needs to provide enough information on these fields to enable
> interoperability. Currently it is not clear if this is the case.
>
> Fields which are not adequately explained include the following:
>
> Section 3.1 Keying-Material
>
> KEK ID
>
> The KEK ID field is 16 octets in length and contains an
> identifier for the KEK. The KEK ID MUST refer to an encryption
> key of a type and length appropriate for use with the algorithm
> specified by the Enc Type field (see above). This key is used
> to protect the contents of the Data field (below). Further
> specification of the content of this field is outside the scope
> of this document.
>
[Joe] Replace first sentence with:
"The KEK ID field is 16 octets in length. The combination of the KEK ID and
the client and ser
