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 server IP addresses together uniquely identify a key shared between the RADIUS client and server. As a result, the KEK ID need not be globally unique." Replace last sentence with: "The KEK ID is a constant that is configured through an out-of-band mechanism. The same value is configured on both the RADIUS client and server. If no KEK ID is configured then the field is set to 0. If only a single KEK is configured for use between a given RADIUS client and server, then 0 can be used as the default value. > KM ID > > The KM ID field is 16 octets in length and contains an > identifier for the contents of the Data field. The KM ID MAY > be used by communicating parties to identify the material being > transmitted. The combination of App ID and KM ID MUST uniquely > identify the keying material between the parties utilizing it. > The KM ID is assumed to be known to the parties that derived > the keying material. If the KM ID is not used it is set to 0. > Further specification of the content of this field is outside > the scope of this document. > [Joe] Remove "further specification... " and replace with: "The KM ID for the EAP-MSK application is set to 0. Another application can be defined in the future which uses the KM ID field. " > Section 3.3 Message-Authentication-Code > > MAC Key ID > > The MAC Key ID field is 16 octets in length and contains an > identifier for the key. The MAC Key ID MUST refer to a key of > a type and length appropriate for use with the algorithm > specified by the MAC Type field (see above). Further > specification of the content of this field is outside the scope > of this document. > [Joe] Replace first sentence with: "The MAC Key ID field is 16 octets in length. The combination of the MAC Key ID and the client and server IP addresses together uniquely identify a key shared between the RADIUS client and server. As a result, the MAC Key ID need not be globally unique." Replace last sentence with: "The MAC Key ID is a constant that is configured through an out-of-band mechanism. The same value is configured on both the RADIUS client and server. If no MAC Key ID is configured, then the field is set to 0. If only a single MAC Key ID is configured for use between a given RADIUS client and server, then 0 can be used as the default value. > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf