RE: Comments on draft-carroll-dynmobileip-cdma-04.txt

["Nelson, David" <dnelson@enterasys.com>]

> It's also been suggested that Access-Request must be integrity
protected
> and authenticated per RFC 2865.  The draft doesn't explicitly require
it,
> but it doesn't preclude it, either; it just says the topic is outside
the
> scope of the document.  I wouldn't have a problem with adding
something to
> 7.9 referencing the requirements of RFC 2865, but I'm having trouble
> finding the right part to reference.  The word "integrity" doesn't
seem to
> appear in the RFC.

RFC 2865 describes the usage of Request-Authenticator and
Response-Authenticator fields to provide some level of message (protocol
payload) integrity protection for messages that contain the User-Name
and User-Password attributes and uses the Message-Authenticator
attribute for messages that contain EAP-Messages or
CHAP-Challenge/CHAP-Password.

The relevant section of RFC 2865 is:

Authenticator

      The Authenticator field is sixteen (16) octets.  The most
      significant octet is transmitted first.  This value is used to
      authenticate the reply from the RADIUS server, and is used in the
      password hiding algorithm.

      Request Authenticator

         In Access-Request Packets, the Authenticator value is a 16
         octet random number, called the Request Authenticator.  The
         value SHOULD be unpredictable and unique over the lifetime of a
         secret (the password shared between the client and the RADIUS
         server), since repetition of a request value in conjunction
         with the same secret would permit an attacker to reply with a
         previously intercepted response.  Since it is expected that the
         same secret MAY be used to authenticate with servers in
         disparate geographic regions, the Request Authenticator field
         SHOULD exhibit global and temporal uniqueness.

         The Request Authenticator value in an Access-Request packet
         SHOULD also be unpredictable, lest an attacker trick a server
         into responding to a predicted future request, and then use the
         response to masquerade as that server to a future Access-
         Request.

         Although protocols such as RADIUS are incapable of protecting
         against theft of an authenticated session via realtime active
         wiretapping attacks, generation of unique unpredictable
         requests can protect against a wide range of active attacks
         against authentication.

         The NAS and RADIUS server share a secret.  That shared secret
         followed by the Request Authenticator is put through a one-way
         MD5 hash to create a 16 octet digest value which is xored with
         the password entered by the user, and the xored result placed
         in the User-Password attribute in the Access-Request packet.
         See the entry for User-Password in the section on Attributes
         for a more detailed description.

      Response Authenticator

         The value of the Authenticator field in Access-Accept, Access-
         Reject, and Access-Challenge packets is called the Response
         Authenticator, and contains a one-way MD5 hash calculated over
         a stream of octets consisting of: the RADIUS packet, beginning
         with the Code field, including the Identifier, the Length, the
         Request Authenticator field from the Access-Request packet, and
         the response Attributes, followed by the shared secret.  That
         is, ResponseAuth =
         MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
         denotes concatenation.

See the following section of RFC 2869 for additional clarification: 

7.1.  Message-Authenticator Security

   Access-Request packets with a User-Password establish the identity of
   both the user and the NAS sending the Access-Request, because of the
   way the shared secret between NAS and RADIUS server is used.
   Access-Request packets with CHAP-Password or EAP-Message do not have
   a User-Password attribute, so the Message-Authenticator attribute
   should be used in access-request packets that do not have a User-
   Password, in order to establish the identity of the NAS sending the
   request.


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