One document matched: draft-irtf-aaaarch-handoff-00.txt
Network Working Group William A. Arbaugh
INTERNET-DRAFT University of Maryland
Category: Experimental
<draft-irtf-aaaarch-handoff-00.txt>
22 February 2003
Experimental Handoff Extension to RADIUS
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet- Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
In order to decrease handoff latency, the concept of pre-emptive
provisioning is under investigation. This document describes an
experimental extension to the RADIUS protocol that enables a RADIUS
server to notify a NAS of a prospective handoff. This enables the NAS to
reserve resources and obtain the session parameters prior to arrival of
the client, potentially reducing handoff times. Whether the approach
described in this document is effective, deployable or secure is a
subject of current research. As a result, implementation of this
extension for purposes other than research is not recommended at this
time.
Arbaugh Experimental [Page 1]
INTERNET-DRAFT Handoff Extension 22 February 2003
Table of Contents
1. Introduction .......................................... 3
1.1 Terminology ..................................... 4
1.2 Requirements language ........................... 5
2. Packet format ......................................... 5
2.1 Notify-Request .................................. 7
2.2 Notify-Accept ................................... 7
2.3 Notify-Reject ................................... 8
3. Attributes ............................................ 9
3.1 Previous-Called-Station-Id ...................... 9
3.2 Table of attributes ............................. 11
4. Security considerations ............................... 13
4.1 IPsec usage guidelines .......................... 13
4.2 Replay protection ............................... 15
5. IANA considerations ................................... 15
6. Normative references .................................. 15
7. Informative references ................................ 16
ACKNOWLEDGMENTS .............................................. 17
AUTHORS' ADDRESSES ........................................... 17
Intellectual Property Statement .............................. 18
Full Copyright Statement ..................................... 18
Arbaugh Experimental [Page 2]
INTERNET-DRAFT Handoff Extension 22 February 2003
1. Introduction
In wireless networks such as IEEE 802.11, described in [IEEE80211], it
may be desirable to improve the speed at which handoff can be completed.
Where RADIUS Accounting [RFC2866] is implemented, RADIUS Accounting
packets will be generated each time the client connects to a NAS.
Accounting packets from a single session, across multiple NASes, are
uniquely identified by the Acct-Multi-Session-Id attribute, described in
[RFC2866] and [Congdon].
The sequence of NASes contacted by clients as they move creates a graph
representing the mobility paths of the clients. We call this graph a
neighbor graph with NASes as the vertices and the mobility paths between
the NASes as the edges. Thus, the number of neighbors for a given NAS is
given by the degree function applied to the vertex representing the
given NAS, e.g. for NAS_A the number of neighbors would be given by
deg(v_A) where deg is the degree function- deg: V -> int. Through
knowledge of the neighbor graph, it is possible for a RADIUS server to
anticipate client movements and provide advance notice of a potential
handoff to the NAS. This advance notice, known as a Notify-Request in
this specification, allows the NAS to reserve resources and obtain the
session authorization parameters prior to arrival of the client. This
removes the latency of the RADIUS exchange from the critical path for
processing a handoff, decreasing handoff latency substantially, as
described in [IEEE-02-758, IEEE-03-084]. Assuming that the coverage area
is over-lapping, this technique can support handoffs at vehicular
velocities. The creation and maintenance of neighbor graphs at an AS is
described in [Mishra].
An alternate approach to using neighbor graphs uses a matrix of
probabilities and is described in [8021XHandoff].
By nature, client behavior is not completely predictable, so that the
handoff advance notice is only advisory. The client identified in the
advance notice may never contact the NAS, or may contact it long after
the initial notice is received. As a result, the NAS will typically free
reserved resources after a suitable waiting period, known as the
Reservation-Lifetime. A client contacting the NAS after the Reservation-
Lifetime has expired will be unable to complete a handoff, and will need
to do a fast resume, such as is supported in EAP TLS [RFC2716].
Arbaugh Experimental [Page 3]
INTERNET-DRAFT Handoff Extension 22 February 2003
The extension described in this document enables a RADIUS Server to send
Notify-Requests to NASes, and to receive Notify-Responses. The Notify-
Request identifies the session to be handed off. Attributes included
within the Notify-Request are described in Section 2.1. If the NAS has
resources available to reserve, and if it is enabled to support this
handoff extension, then it will respond with a Notify-Accept. If
resources are not available (such as when previous resource commitments
leave insufficient resources remaining), or if the NAS does not wish to
support the handoff for any other reason, the NAS will respond with a
Notify-Reject, specifying the reason why the requested handoff
reservation could not be carried out.
After the NAS responds with a Notify-Accept, it will typically issue an
Access-Request to the RADIUS server. This allows the NAS to obtain the
authorizations for the session before it is contacted by the client. The
contents of the Access-Request sent by the NAS will depend on the form
of access it is providing, so that it cannot be specified in detail
here. However, for use with IEEE 802.11, it is expected that an Access-
Request will be sent with a NAS-Port-Type=802.11 and a Service-
Type=Handoff. For other access methods, a different NAS-Port-Type value
might be sent, along with a different value for Service-Type.
1.1. Terminology
This document uses the following terms:
Authenticator
An Authenticator is an entity that require authentication from
the Supplicant. The Authenticator may be connected to the
Supplicant at the other end of a point-to-point LAN segment or
802.11 wireless link.
Authentication Server
An Authentication Server is an entity that provides an
Authentication Service to an Authenticator. This service
verifies from the credentials provided by the Supplicant, the
claim of identity made by the Supplicant.
Network Access Server (NAS)
The device providing access to the network.
Service The NAS provides a service to the user, such as IEEE 802 or
PPP.
Port Access Entity (PAE)
The protocol entity associated with a physical or virtual
(802.11) Port. A given PAE may support the protocol
functionality associated with the Authenticator, Supplicant or
Arbaugh Experimental [Page 4]
INTERNET-DRAFT Handoff Extension 22 February 2003
both.
Session Each service provided by the NAS to a user constitutes a
session, with the beginning of the session defined as the
point where service is first provided and the end of the
session defined as the point where service is ended. A user
may have multiple sessions in parallel or series if the NAS
supports that, with each session generating a separate start
and stop accounting record. Where the client is mobile and is
able to handoff between NASes, multiple related sessions may
be uniquely identified by the Acct-Multi-Session-Id attribute.
Supplicant
A Supplicant is an entity that is being authenticated by an
Authenticator. The Supplicant may be connected to the
Authenticator at one end of a point-to-point LAN segment or
802.11 wireless link.
1.2. Requirements language
In this document, several words are used to signify the requirements of
the specification. These words are often capitalized. The key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119].
2. Packet format
Exactly one Notify-Request, Notify-Accept or Notify-Reject packet is
encapsulated in the UDP Data field. For the Notify-Request packet, the
UDP Destination Port field is TBD. When a reply is generated, the
source and destination ports are reversed.
A summary of the data 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Arbaugh Experimental [Page 5]
INTERNET-DRAFT Handoff Extension 22 February 2003
Code
The Code field is one octet, and identifies the type of RADIUS
packet. When a packet is received with an invalid Code field, it is
silently discarded. RADIUS codes (decimal) for this extension are
assigned as follows:
TBD - Notify-Request
TBD - Notify-Accept
TBD - Notify-Reject
Identifier
The Identifier field is one octet, and aids in matching requests and
replies. The RADIUS server can detect a duplicate request if it has
the same client source IP address and source UDP port and Identifier
within a short span of time.
Length
The Length field is two octets. It indicates the length of the
packet including the Code, Identifier, Length, Authenticator and
Attribute fields. Octets outside the range of the Length field MUST
be treated as padding and ignored on reception. If the packet is
shorter than the Length field indicates, it MUST be silently
discarded. The minimum length is 20 and maximum length is 4096.
Authenticator
The Authenticator field is sixteen (16) octets. The most significant
octet is transmitted first. This value is used to authenticate the
messages between the client and RADIUS server.
Request Authenticator
In Notify-Request Packets, the Authenticator value is a 16 octet MD5
[RFC1321] checksum, called the Request Authenticator. The Request
Authenticator is calculated the same way as for an Accounting-
Request, specified in [RFC2866].
Note that the Request Authenticator of an Notify-Request can not be
done the same way as the Request Authenticator of a RADIUS Access-
Request, because there is no User-Password attribute in an Notify-
Request.
Response Authenticator
The Authenticator field in a Notify-Accept or Notify-Reject packet is
Arbaugh Experimental [Page 6]
INTERNET-DRAFT Handoff Extension 22 February 2003
called the Response Authenticator, and contains a one-way MD5 hash
calculated over a stream of octets consisting of the Notify-Response
Code, Identifier, Length, the Request Authenticator field from the
Notify-Request packet being replied to, and the response attributes
if any, followed by the shared secret. The resulting 16 octet MD5
hash value is stored in the Authenticator field of the Notify-Accept
or Notify-Reject packet.
Attributes
Attributes may have multiple instances, in such a case the order of
attributes of the same type SHOULD be preserved. The order of
attributes of different types is not required to be preserved.
2.1. Notify-Request
Description
A Notify-Request packet is sent by the RADIUS server to the NAS to
notify it of the potential handoff of a specified session.
Code
TBD - Notify-Request
Identifier
The Identifier field MUST be changed whenever the content of the
Attributes field changes, and whenever a valid reply has been
received for a previous request. For retransmissions where the
contents are identical, the Identifier MUST remain unchanged.
Note that if the Event-Timestamp attribute is included the Notify-
Request then the Event-Timestamp value will be updated when the
packet is retransmitted, changing the content of the Attributes field
and requiring a new Identifier and Request Authenticator.
Request Authenticator
The Request Authenticator of an Accounting-Request contains a
16-octet MD5 hash value calculated according to the method described
in "Request Authenticator" in Section 2.
Attributes
The Attribute field is variable in length, and contains a list of
Attributes. Within the Notify-Request, Attributes are used to
uniquely identify the user session that may potentially be handed off
Arbaugh Experimental [Page 7]
INTERNET-DRAFT Handoff Extension 22 February 2003
to the NAS, and to describe the services expected to be provided.
Where RADIUS is not protected by IPsec, the Event-Timestamp attribute
MUST be included so as to protect against replay attacks. Section
3.4 provides more detail on the attributes permitted within the
Notify-Request packet.
2.2. Notify-Accept
Description
The NAS responds to the Notify-Request with a Notify-Accept if the
NAS agrees to to prepare for a handoff of the specified session.
Code
TBD - Notify-Accept
Identifier
The Identifier field is a copy of the Identifier field of the Notify-
Request which caused this Notify-Accept.
Response Authenticator
The Response Authenticator of a Notify-Accept contains a 16-octet MD5
hash value calculated according to the method described in "Response
Authenticator" in Section 2.
Attributes
The Attribute field is variable in length, and contains a list of
Attributes. Within the Notify-Accept, attributes are used to provide
the RADIUS server with the session identifiers that will be used by
the NAS in subsequent Access-Request and Accounting-Request packets.
This includes the User-Name and Acct-Multi-Session-Id attributes
originally provided by the RADIUS server in the Notify-Request, as
well as an Acct-Session-Id allocated by the NAS for the handoff,
should it occur. The Idle-Timeout attribute, when included in the
Notify-Accept, provides the RADIUS server with the time that the NAS
is willing to reserve resources for the handoff. Where RADIUS is not
protected by IPsec, the Event-Timestamp attribute MUST be included so
as to protect against replay attacks. Section 3.4 provides more
detail on the attributes permitted within the Notify-Accept packet.
2.3. Notify-Reject
Description
Arbaugh Experimental [Page 8]
INTERNET-DRAFT Handoff Extension 22 February 2003
The NAS responds to the Notify-Request with a Notify-Reject if the
NAS does not have the resources to make the required handoff
preparations, or wishes to decline for any other reason.
Code
TBD - Notify-Reject
Identifier
The Identifier field is a copy of the Identifier field of the Notify-
Request which caused this Notify-Reject.
Response Authenticator
The Response Authenticator of a Notify-Accept contains a 16-octet MD5
hash value calculated according to the method described in "Response
Authenticator" in Section 2.
Attributes
The Attribute field is variable in length, and contains a list of
Attributes. Within the Notify-Reject, attributes are used to provide
the RADIUS server with the reason why the Notify-Request could not be
honored. If the NAS is configured so as not to support the Handoff
extension, then an Acct-Terminate-Cause attribute with a value of
Admin Reset (5) is included. If the service described in the Notify-
Request is not supported, then an Acct-Terminate-Cause attribute with
a value of Service Unavailable (15) is included. If resources are not
available, then an Acct-Terminate-Cause of Port Preempted (13) is
included. Where RADIUS is not protected by IPsec, the Event-
Timestamp attribute MUST be included so as to protect against replay
attacks. Section 3.4 provides more detail on the attributes
permitted within the Notify-Reject packet.
3. Attributes
3.1. Previous-Called-Station-Id
Description
This Attribute allows the RADIUS server to send in the Notify-Request
packet the link layer address of the NAS that the user last connected
to. For IEEE 802.1X Authenticators, this attribute is used to store
the bridge or Access Point MAC address in ASCII format, with octet
values separated by a "-". Example: "00-10-A4-23-19-C0". In IEEE
802.11, where the SSID is known, it SHOULD be appended to the Access
Point MAC address, separated from the MAC address with a ":".
Arbaugh Experimental [Page 9]
INTERNET-DRAFT Handoff Extension 22 February 2003
Example "00-10-A4-23-19-C0:AP1". In the case of a dialup network,
this would be the phone number that the user called, using Dialed
Number Identification (DNIS) or similar technology. It is only used
in Notify-Request packets.
Arbaugh Experimental [Page 10]
INTERNET-DRAFT Handoff Extension 22 February 2003
A summary of the Previous-Called-Station-Id Attribute format is shown
below. The fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
TBD
Length
>=3
String
The String field is one or more octets, containing the link layer
address that the user session last connected to. The actual format
of the information is site or application specific. A robust
implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
Arbaugh Experimental [Page 11]
INTERNET-DRAFT Handoff Extension 22 February 2003
3.2. Table of Attributes
The following table provides a guide to which attributes may be found in
which kinds of packets, and in what quantity. If an attribute is not
mentioned in this table, then it is not permitted in Notify-Request,
Notify-Accept or Notify-Reject packets.
Notify Notify Notify
Request Accept Reject # Attribute
0-1 0-1 0 1 User-Name [Note 1]
0-1 0 0 4 NAS-IP-Address [Note 2]
1 0 0 6 Service-Type [Note 10,11]
0-1 0 0 7 Framed-Protocol [Note 10]
0-1 0-1 0 28 Idle-Timeout [Note 3]
0-1 0 0 30 Called-Station-Id [Note 4]
0-1 0 0 31 Calling-Station-Id [Note 1]
0-1 0 0 32 NAS-Identifier [Note 2]
0+ 0+ 0+ 33 Proxy-State
0 0-1 0 44 Acct-Session-Id [Note 7]
0 0 0-1 49 Acct-Terminate-Cause [Note 8]
0-1 0-1 0 50 Acct-Multi-Session-Id [Note 6]
1 1 1 55 Event-Timestamp [Note 9]
1 0 0 61 NAS-Port-Type [Note 10]
0-1 0 0 TBD Previous-Called-Station-Id [Note 5]
Notify Notify Notify
Request Accept Reject # Attribute
[Note 1] The User-Name attribute, if provided in the Notify-Request
MUST be echoed in the Notify-Accept, and subsequent Access-Request
packets. If the User-Name attribute is not provided, then it is
assumed that the identity is provided by the Calling-Station-Id field,
which MUST be present.
[Note 2] A Notify-Request MUST contain either a NAS-IP-Address or a
NAS-Identifier (or both).
[Note 3] Within a Notify-Request, the Idle-Timeout attribute provides
a suggested amount of time for which the NAS may reserve resources for
a potential handoff. If an Idle-Timeout attribute is included within
the Notify-Request, then if the NAS is unable to reserve resources
for this period of time, then it MUST include an Idle-Timeout attribute
in the Notify-Accept, if sent, specifying the time it is willing to
commit to. The RADIUS server should assume that the resources have
been released at time Event-Timestamp + Idle-Timeout.
[Note 4] Within a Notify-Request, the Called-Station-Id refers to the
NAS to which the Notify-Request is sent. If it this does not match
the actual value of the NAS Called-Station-Id, then a Notify-Reject
Arbaugh Experimental [Page 12]
INTERNET-DRAFT Handoff Extension 22 February 2003
MUST be sent.
[Note 5] Within a Notify-Request, the Previous-Called-Station-Id refers
to the
NAS from which the handoff is expected to occur. If the handoff does
not occur from that NAS, then the NAS receiving the handoff MAY reject
access. In the case where NAS-Port-Type = 802.11, and the
Previous-Called-Station-Id contains an SSID, then if the handoff occurs,
the client MUST be granted access only to this SSID. If the
attempts to connect to another SSID, then the NAS MUST deny network
access to the client. If the SSID field is omitted, then a value of ANY
is assumed.
[Note 6] Within a Notify-Request, the Acct-Multi-Session-Id provides a
unique identifier for the client sessions during handoffs between
NASes. The Acct-Multi-Session-Id is echoed in subsequent Access-Request
and Accounting-Request packets.
[Note 7] The Acct-Session-Id, if present in Notify-Accept packets,
denotes
the accounting session id allocated by the NAS for the prospective
handoff,
should it occur. The Acct-Session-Id is echoed in subsequent
Access-Request
and Accounting-Request packets.
[Note 8] The Acct-Terminate-Cause is present only in Notify-Reject
packets,
and specifies the reason for the rejection.
[Note 9] When RADIUS is not protected by IPsec, the
Event-Timestamp attribute MUST be present in all packets in order to
prevent replay attacks. This is discussed in Section 4.
[Note 10] The Service-Type, NAS-Port-Type and Framed-Protocol
attributes are used to specify the services that are
to be provided to the handed off session.
The Service-Type and NAS-Port-Type attributes
MUST be present in the Notify-Request; when used with 802.11,
it is expected that a NAS-Port-Type=802.11 and a Service-Type=Handoff
will be included. The Service-Type is echoed in the subsequent
Access-Request. If the NAS is not able to provide
the specified service, then it MUST send a Notify-Reject.
[Note 11] The Service-Type value of Handoff, when used by the NAS in an
Access-Request packet, indicates that a handoff request is
being anticipated and that the RADIUS server should send back an
Access-Accept to allow the prospective handoff to occur, or an
Access-Reject to deny the prospective handoff. The decision is
typically based on the User-Name, Called-Station-Id or
Calling-Station-Id. As with a normal Access-Request, the
User-Name attribute is expected to be filled in. Note that the
service provided when Service-Type=Handof differs from
that provided when Service-Type=Call Check.
Arbaugh Experimental [Page 13]
INTERNET-DRAFT Handoff Extension 22 February 2003
With Handoff, the NAS MUST authenticate the user during
the handoff prior to allowing access, using credentials provided
by the RADIUS server, whereas with a Service-Type=Call Check,
the authentication is implicit and access is permitted or denied
purely based on the Called-Station-Id or Calling-Station-Id.
The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in packet.
0-1 Zero or one instance of this attribute MAY be present in packet.
1 Exactly one instance of this attribute MUST be present in packet.
4. Security considerations
4.1. IPsec usage guidelines
Implementations of this specification SHOULD support IPsec [RFC2401]
along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with
non-null transform, and per-packet authentication, integrity and replay
protection SHOULD be used, along with IKE for key management.
Within RADIUS [RFC2865], a shared secret is used for hiding of
attributes such as User-Password, as well as in computation of the
Response Authenticator. In RADIUS accounting [RFC2866], the shared
secret is used in computation of both the Request Authenticator and the
Response Authenticator.
Since in RADIUS a shared secret is used to provide confidentiality as
well as integrity protection and authentication, only use of IPsec ESP
with a non-null transform can provide security services sufficient to
substitute for RADIUS application-layer security. Therefore, where
IPSEC AH or ESP null is used, it will typically still be necessary to
configure a RADIUS shared secret.
Where RADIUS is run over IPsec ESP with a non-null transform, the secret
shared between the NAS and the RADIUS server may not be configured. In
this case, a shared secret of zero length MUST be assumed. However, a
RADIUS server that cannot know whether incoming traffic is IPsec-
protected MUST be configured with a non-null RADIUS shared secret. When
IPsec ESP is used with RADIUS, DES-CBC SHOULD NOT be used as the
encryption transform, and per-packet authentication, integrity and
replay protection MUST be used.
A typical IPsec policy for an IPsec-capable RADIUS client is "Initiate
IPsec, from me to any, destination port UDP 1812". This causes an IPsec
SA to be set up by the RADIUS client prior to sending RADIUS traffic to
any RADIUS server. If some RADIUS servers contacted by the client do not
Arbaugh Experimental [Page 14]
INTERNET-DRAFT Handoff Extension 22 February 2003
support IPsec, then a more granular policy will be required.
For a client implementing this specification the policy would be "Accept
IPsec, from any to me, destination port UDP TBD". This causes the RADIUS
client to accept (but not require) use of IPsec. It may not be
appropriate to require IPsec for all RADIUS servers connecting to an
IPsec-enabled RADIUS client, since some RADIUS servers may not support
IPsec.
For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept
IPsec, from any to me, destination port 1812". This causes the RADIUS
server to accept (but not require) use of IPsec. It may not be
appropriate to require IPsec for all RADIUS clients connecting to an
IPsec-enabled RADIUS server, since some RADIUS clients may not support
IPsec.
For servers implementing this specification, the policy would be
"Initiate IPsec, from me to any, destination port UDP TBD". This causes
the RADIUS server to initiate IPsec when sending RADIUS extension
traffic to any RADIUS client. If some RADIUS clients contacted by the
server do not support IPsec, then a more granular policy will be
required.
Where IPsec is used for security, and no RADIUS shared secret is
configured, it is important that trust be demonstrated between the
RADIUS client and RADIUS server by some means. For example, before
enabling an IKE-authenticated host to act as a RADIUS client, the RADIUS
server should check whether the host is authorized to provide network
access. For example, the RADIUS server can be configured with the IP
addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for
certificate authentication) of RADIUS clients.
Alternatively, if a separate CA exists for RADIUS clients, then the
RADIUS server can configure this CA as a trusted root for use with
IPsec. However, unlike SSL/TLS, IKE does not permit certificate policies
to be set on a per-port basis, such a policy would need to apply to all
uses of IPsec on RADIUS clients and servers. Assuming that only
certificate authentication is supported in the deployment, a management
station initiating an IPsec-protected telnet session to the RADIUS
server would need to obtain a certificate chaining to the RADIUS client
CA. Issuing such a certificate might not be appropriate if the
management station was not authorized as a RADIUS client.
Where RADIUS clients may obtain their IP address dynamically (such as an
Access Point supporting DHCP), Main Mode with pre-shared keys [RFC2409]
SHOULD NOT be used, since this requires use of a group pre-shared key;
instead, Aggressive Mode SHOULD be used. Where RADIUS client addresses
are statically assigned either Aggressive Mode or Main Mode MAY be used.
Arbaugh Experimental [Page 15]
INTERNET-DRAFT Handoff Extension 22 February 2003
With certificate authentication, Main Mode SHOULD be used.
Care needs to be taken with IKE Phase 1 Identity Payload selection in
order to enable mapping of identities to pre-shared keys even with
Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity
Payloads are used and addresses are dynamically assigned, mapping of
identities to keys is not possible, so that group pre-shared keys are
still a practical necessity. As a result, the ID_FQDN identity payload
SHOULD be employed in situations where Aggressive mode is utilized along
with pre-shared keys and IP addresses are dynamically assigned. This
approach also has other advantages, since it allows the RADIUS server
and client to configure themselves based on the fully qualified domain
name of their peers.
Note that with IPsec, security services are negotiated at the
granularity of an IPsec SA, so that RADIUS exchanges requiring a set of
security services different from those negotiated with existing IPsec
SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also
advisable where quality of service considerations dictate different
handling RADIUS conversations. Attempting to apply different quality of
service to connections handled by the same IPsec SA can result in
reordering, and falling outside the replay window. For a discussion of
the issues, see [RFC2983].
4.2. Replay protection
Since this specification utilizes the Request Authenticator field for
integrity protection and authentication, rather than as a nonce, no
liveness or protection against replay is provided by the RADIUS header.
Where IPsec is not used, in order to provide replay protection, the
Event-Timestamp (55) attribute, described in [RFC2869] MUST be included.
When this attribute is present, the RADIUS server MUST check that the
Event-Timestamp is current within an acceptable time window. This
implies the need for time synchronization within the network, which can
be achieved via a variety of mechanisms, including secure NTP, as
described in [NTPAuth]. A default time window of 300 seconds is
recommended.
5. IANA Considerations
This specification requires assignment a UDP port, in addition to RADIUS
Type codes for Notify-Request, Notify-Accept, and Notify-Reject.
Assignment of Attribute Type codes are also required for the following
attributes: Previous-Called-Station-Id. A new value is requested to be
allocated for the Service-Type attribute for Handoff.
Arbaugh Experimental [Page 16]
INTERNET-DRAFT Handoff Extension 22 February 2003
6. Normative references
[RFC1305] Mills, D. L., "Network Time Protocol (version 3)
Specification, Implementation and Analysis, RFC 1305
March, 1992.
[RFC1321] Rivest, R., Dusse, S., "The MD5 Message-Digest
Algorithm", RFC 1321, April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997.
[RFC2865] Rigney, C., Rubens, A., Simpson, W., Willens, S.,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS
Extensions", RFC 2869, June 2000.
[RFC3162] Aboba, B., Zorn, G., Mitton, D.,"RADIUS and IPv6", RFC
3162, August 2001.
[IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1X-2001,
June 2001.
[Congdon] Congdon, P., et al., "IEEE 802.1X RADIUS Usage
Guidelines", Internet draft (work in progress), draft-
congdon-radius-8021x-21.txt, January 2003.
[DynAuth] Chiba, M., et. al., "Dynamic Authorization Extensions to
Remote Authentication Dial-in User Service (RADIUS)",
Internet draft (work in progress), draft-chiba-radius-
dynamic-authorization-05.txt, August 2002.
7. Informative references
[Mishra] Mishra, A., Shin, M., Arbaugh, W., Lee, I., Jang, K.,
"Experimental Neighbor Graph Creation and Maintenance",
Internet draft (work in progress), draft-irtf-aaaarch-
neighbor-graph-00.txt.
[RFC2104] Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997
Arbaugh Experimental [Page 17]
INTERNET-DRAFT Handoff Extension 22 February 2003
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2607] Aboba, B., Vollbrecht, J., "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[RFC2716] Aboba, B., Simon, D., "PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999.
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE8021Q] IEEE Standards for Local and Metropolitan Area Networks:
Draft Standard for Virtual Bridged Local Area Networks,
P802.1Q, January 1998.
[IEEE-02-758] Mishra, A., Shin, M., Arbaugh, W., Lee, I., Jang, K.,
"Proactive Caching Strategies for IAPP Latency
Improvement during 802.11 Handoff", IEEE 802.11 Working
Group, IEEE-02-758r1-F, November 2002.
[IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I., Jang, K.,
"Proactive Key Distribution to support fast and secure
roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I,
http://www.ieee802.org/11/Documents/DocumentHolder/3-084.zip,
January 2003.
[8021XHandoff] Pack, S., Choi, Y., "Pre-Authenticated Fast Handoff in a
Public Wireless LAN Based on IEEE 802.1X Model", School
of Computer Science and Engineering, Seoul National
University, Seoul, Korea, 2002.
[IEEE8023] ISO/IEC 8802-3 Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks - Common
specifications - Part 3: Carrier Sense Multiple Access
with Collision Detection (CSMA/CD) Access Method and
Physical Layer Specifications, (also ANSI/IEEE Std 802.3-
1996), 1996.
[IEEE80211] Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific Requirements Part
11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications, IEEE Std.
802.11-1999, 1999.
Arbaugh Experimental [Page 18]
INTERNET-DRAFT Handoff Extension 22 February 2003
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack."
CryptoBytes Vol.2 No.2, Summer 1996.
[NTPAuth] Mills, D., "Public Key Cryptography for the Network Time
Protocol", Internet draft (work in progress), draft-ietf-
stime-ntpauth-05.txt, November 2002.
Acknowledgments
The authors would like to acknowledge the following people for
contributions on this document: Tim Moore (Microsoft), Min-ho Shin
(University of Maryland), Nick Petroni (University of Maryland), Adam
Sulmicki (University of Maryland), Insun Lee (Samsung Electronics),
Kyunghun Jang (Samsung Electronics).
Authors' Addresses
William A. Arbaugh
Department of Computer Science
University of Maryland, College Park
A.V. Williams Building
College Park, MD 20742
EMail: waa@cs.umd.edu
Phone: +1 301 405 2774
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive
Director.
Arbaugh Experimental [Page 19]
INTERNET-DRAFT Handoff Extension 22 February 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English. The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Arbaugh Experimental [Page 20]
INTERNET-DRAFT Handoff Extension 22 February 2003
Expiration Date
This memo is filed as <draft-irtf-aaarch-handoff-00.txt>, and expires
August 22, 2003.
Arbaugh Experimental [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-22 04:54:32 |