[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
- To: "Frank Quick" <fquick@qualcomm.com>, "Jari Arkko" <jari.arkko@piuha.net>
- Subject: RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
- From: "Nelson, David" <dnelson@enterasys.com>
- Date: Fri, 4 Mar 2005 15:13:31 -0500
- Cc: "Barney Wolff" <barney@databus.com>, <gwz@cisco.com>, "Avi Lior" <avi@bridgewatersystems.com>, "Thomas Narten" <narten@us.ibm.com>, "W. Mark Townsley" <townsley@cisco.com>, "Carroll, Christopher P." <Ccarroll@ropesgray.com>, <gerry.flynn@verizonwireless.com>, <radiusext@ops.ietf.org>
> 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/>