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