Review of draft-gaonkar-radext-erp-attrs-02.txt

[Alan DeKok <[e-mail]>]

  I've read the draft, and have a few comments.

   These
   attributes can be used by a visited network entity to request a key
   from the home network and the home domain to deliver the key to the
   visited network entity

  Why is the visited network requesting keys?  Is the user involved in
this request?  Does the user know that the visited network is requesting
keys on his behalf?

  These issues are referenced in the security section.  However, that
section says that channel bindings *may* be necessary.  It looks to me
like they are required to avoid a large class of security / information
leakage.

   The key-request attribute contains the requesting entity's identity
   and the type of the key being requested.

  Why is it necessary to have the requesting entities identity?  Can
multiple servers in a proxy chain make requests at the same time?  If
so, why?  What benefit does this serve?

   The key-response attribute contains the requesting entity's identity,
   the type of the key, the key itself, its length, name and lifetime.

  Are key lifetimes different from user session lifetimes?  RADIUS
already has support for Session-Timeout, which would seem to put an
upper limit on key lifetimes, at least for one session.  Are these keys
to be cached across multiple user sessions?  If so, this document should
say.

[ key request attribute ]

      The Requesting Entity's Identity is to be copied in the
      corresponding Key-Response attribute.

  The following section says that the response MAY include the identity.
   That section then says the identity "is to be included".  The text
should agree with itself.

  The next section says that the identity can be only 192 octets in
length, but that limitation is not discussed here.  It should be.

  The guidelines document discusses packing multiple fields into one
attribute:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt

  The document doesn't say whether or not only one key-request attribute
is permitted in an Access-Request.  If only one is permitted, then all
of the packed fields in both attributes MUST be broken out into separate
attributes.  That will enable legacy implementations to deal with the
attributes.  i.e. not only support them, but enforce policies based on them.

  What is the purpose of the "key name" field?  This document doesn't
say, and it doesn't refer to other documents which could explain the
utility of that field.  Including a key name in a key response attribute
would seem to indicate that more than one key response is permitted in
an Access-Accept.  If so, this needs to be explained, including
use-cases.  If not, the key name is not needed.

      A stricter version of RFC 3756 requirements apply for RADIUS
      messages carrying Key-Response Attribute(s).  Implementations of
      this specification MUST support IPsec along with IKEv2 for key
      management.  IPsec ESP with a non-null transform MUST be
      supported, and IPsec ESP with a non-null encryption transform and
      authentication support is necessary to provide per-packet
      confidentiality, authentication, integrity and replay protection.


  This requirement imposes a heavy burden on any implementation of this
proposal.  Most existing RADIUS EAP deployments do not use IPSec as a
transport layer.  I also question the necessity for exposing the DSRK
"in the clear" to all parties in the AAA conversation.

  i.e. in a proxy environment, entities who transport the traffic do NOT
request the key, but can see it "in the clear".  Not only that, but they
can modify the key without detection, as the key is not authenticated.
This issue is not discussed in the security section.

  It would also appear to be a fatal flaw in this proposal: keys being
exposed to entities that don't need to see the key, and lack of
integrity checks on the keys themselves.

  I question why the visited *network* needs the DSRK, as opposed to the
visited *NAS*.  This document does not discuss any use-cases or
requirements that would make this distinction clear.

  From what I see, only the NAS requires access to any keying material.
 For security, we can presume that the keys are opaque to everyone on
the network other than the user and the home server which authenticates
that user.  Anyone else needing access to those keys can prove their
need to either the user, or to the home server.  And in general, no one
needs to get the key from the home server,

  Since the NAS is already in direct contact with the user, it becomes
clear that the NAS can ask the user how to interpret any keying material
it has.  Since that keying material is opaque to everyone else, there is
no security issue with it being exposed, because it has no useful
information.  Since that keying material is opaque, anyone and everyone
with access to it can cache it.

  See the following message for a short exposition of the concepts
outlined above:

http://ops.ietf.org/lists/radiusext/2007/msg01001.html

  That proposal would seem to meet the requirements outlined for this
document, from what I can understand.  (The requirements and use-cases
outlined here are unclear).  That proposal can be modified to include
key lifetime, if necessary.  That proposal avoids all of the security
issues inherent in this design.

  For this proposal to move forward, it needs to have clearer use-cases
and requirements.  And it needs to address the security issues that are
currently fatal flaws.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>