[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposed Resolution to RFC 3576bis Issue 139: Nonce Attribute
The text of Issue 139 is enclosed below. The proposed resolution is as
follows:
Add the following text to Section 1.1:
" Existing implementations lack replay protection. In order to support
replay detection, it is recommended that a Nonce or Event-Timestamp
Attribute be added to all messages in situations where IPsec replay
protection is not employed. See Section 6.4 for details."
Change the last two paragraphs of Section 3 to the following:
" Where a Service-Type Attribute with value "Authorize Only" is
included within a CoA-Request, attributes representing an
authorization change MUST NOT be included; only NAS or session
identification attributes are permitted, as well as Service-Type,
Nonce and State attributes. If other attributes are included in such
a CoA-Request, implementations MUST send a CoA-NAK; an Error-Cause
Attribute with value "Unsupported Attribute" MAY be included.
A Disconnect-Request MUST contain only NAS and session identification
attributes (see Section 3), as well as Service-Type, Nonce and State
attributes. If other attributes are included in a Disconnect-
Request, implementations MUST send a Disconnect-NAK; an Error-Cause
Attribute with value "Unsupported Attribute" MAY be included."
Add Section 3.2:
"3.3. Nonce
Description
Since the Request Authenticator field within CoA-Request
Disconnect-Request packets does not contain a nonce, these packets
are vulnerable to replay attack without the countermeasures
described in Section 6.4. As noted in Section 6.4, replay attacks
can be addressed by using IPsec to protect RADIUS or by adding an
Event-Timestamp attribute to CoA and Disconnect-Request packets.
Since use of the Event-Timestamp Attribute requires time
synchronization, where this is not possible an alternative replay
protection mechanism is required. For this purpose, a Nonce
Attribute MAY be included within CoA-Request, Disconnect-Request,
and Accounting-Request packets.
A summary of the Nonce Attribute format is shown below. The
fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD for Nonce
Length
6
Value
The Value field is four octets, containing a randomly chosen value
[RFC4086]."
Add the following entries to the Attribute Table (Section 3.5) for both
Disconnect and CoA messages:
" 0-1 0-1 0-1 TBD Nonce [Note 8]
[Note 8] A Nonce Attribute SHOULD be included in a CoA-Request or
Disconnect-Request packet that is not protected by IPsec or does not
contain an Event-Timestamp Attribute, so as to prevent replay
attacks. A Nonce Attribute MAY also be included in CoA-ACK, CoA-NAK,
Disconnect-ACK, Disconnect-NAK, or Accounting-Request packets."
--------------------------------------------------------------------------------------------------------------
Issue 139: Nonce Attribute
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: October 10, 2005
Reference:
Document: RFC3576bis-00
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
It has been pointed out that the replay protection mechanisms
recommended in RFC 3576 may be difficult to deploy.
For example, the Event-Timestamp attribute requires time synchronization
between the RADIUS server and NAS. In roaming situations this would
require all networks between the RADIUS server and NAS to be running
NTP, synchronized to the same clock.
Similarly, IPsec with replay protection may not be deployable on all
hops in the path.
To provide more deployable replay protection it has been suggested that
a Nonce attribute be introduced. This attribute would be sent by the DAC
in a CoA/Disconnect-Request. If the DAS understands the attribute it would
be copied into the CoA/Disconnect ACK/NAK (possibly along with another
Nonce-attribute inserted by the DAS).
The Nonce attribute could also be used to enhance replay protection
in Accounting-Request packets. Since the receiver of the packet
with a Nonce attribute doesn't need to understand it, this attribute
is backward compatible with existing RFC 3576 implementations.
--
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/>