a review of draft-gaonkar-radext-erp-attrs-02.txt

["Dan Harkins" <dharkins@lounge.org>]

  Hello,

  I took a look at draft-gaonkar-radext-erp-attrs-02.txt and have
a few suggestions.

  First of all I suggest the Security Considerations be expanded
considerably. RFC4962 provides guidance to AAA key management protocols
and I would consider the key request/response from this draft to fall
into that category. This RFC lists mandatory requirements that acceptable
key management solutions MUST comply with and provides recommendations
that acceptable key management solutions SHOULD comply with. It is my
understanding that certain of these requirements and recommendations
cannot be supported by this draft and those should be explicitly spelled
out in the Security Considerations with text explaining why RFC4962 is
not being adhered to.

  For instance:

   - Prevent the Domino Effect
     The requirement is that compromise of a single entity (with the
     obvious exception of the root of a key hierarchy, e.g. the holder
     of the EMSK) will not affect keys held by other entities. This
     is not possible when proxies are involved.

     The RFC also states in the section on preventing the Domino Effect:
     "There are many implications of this requirement; however, two
     implications deserve highlighting.  First, the scope of the keying
     material must be defined and understood by all parties that
     communicate with a party that holds that keying material.  Second,
     a party that holds keying material in a key hierarchy must not share
     that keying material with parties that are associated with other
     branches in the key hierarchy."

     When proxies are involved I am not sure how the scope of the keying
     material can be defined and understood by all parties when knowledge
     of whether a proxy exists may not even be available to the other
     parties, for instance the peer. Also, when proxies are involved how
     are they going to be bypassed such that knowledge of multiple branches
     of a single key hierarchy will not be provided to a given proxy? I
     don't believe it's possible and the draft must address this.

   - Bind Key to Its Context
     The context bound to a key MUST include: "[t]he other parties that
     are expected to have access to the keying material." It is not clear
     how this can be adhered to when proxies are involved.

     It goes on to state: "In addition, the protocol MUST ensure that all
     parties with legitimate access to keying material have the same
     context for the keying material.  This requires that the parties are
     properly identified and authenticated, so that all of the parties
     that have access to the keying material can be determined." Again,
     it is not clear from the draft how all proxies (or even the existance
     of a single proxy) can be determined such that they can be identified.
     If it is not possible then the draft has to explain this.

  The Security Considerations has to explain the implications of sharing
keys like this, how proxies affect the security of a system implementing
this draft, and why mandatory requirements of an applicable RFC are not
being followed.

  My second suggestion is that the "key name" field be made variable.
Based on reading of related drafts it is apparent that SHA-256 is being
used to generate a unique string based on some key label and other cruft
and that output is being truncated to 8 bytes, hence the field is 8 bytes.
(The motivation for using such a strong mixing function only to throw
away most of the result should be mentioned _somewhere_!) But as long as
189 other possible key names it seems shortsighted to believe that everyone
else will generate 8 byte key names. For instance, RADEXT is considering
a keywrap draft that allots 20 bytes to key names. 802.11r is generating
key names that are 16 bytes. I'm not saying that this draft will be used
to request 802.11r keys but merely pointing out that there is no standard
size for a "key name" and it would be prudent to not fix one here,
especially one that is on the small end of the scale.

  My last comment concerns IPsec. A RADIUS client and RADIUS server cannot
know whether the data they send down to the IP layer is going to end up
being protected or not. I think that if a key is being sent by some
entity then that entity has to ensure it is being protected adequately
and to know that the entity has to protect the key itself. Either (D)TLS
should be specified or a key-wrapping scheme, preferably based on the SIV
mode of AES, be specified. Please do not mandate the use of IPsec with
RADIUS.

  regards,

  Dan.




--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>