Mobile IP Working Group N. Asokan
INTERNET DRAFT Patrik Flykt
20 November 2000 Charles E. Perkins
Nokia
Thomas Eklund
Xelerated Networks
AAA for IPv6 Network Access
draft-perkins-aaav6-01.txt
Status of This Memo
This document is a submission by the ipng Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the ipng@sunroof.eng.sun.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
Abstract
IPv6 nodes (clients) need a way to offer credentials to a local
AAA in order to be granted access to the local network. For
IPv6, it will be more efficient and thus reasonable to expect such
access controls to be exerted by IPv6 routers, possibly as part of
performing their role as DHCPv6 relays. DHCPv6 servers and routers
are expected to work in conjunction with AAA servers to determine
whether or not the client's credentials are valid.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page i]
Internet Draft AAA for IPv6 20 November 2000
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Terminology 1
3. General Framework 4
3.1. Client requirements . . . . . . . . . . . . . . . . . . . 5
3.2. Attendant requirements . . . . . . . . . . . . . . . . . 5
3.3. AAAL requirements . . . . . . . . . . . . . . . . . . . . 5
3.4. Requirements for other nodes . . . . . . . . . . . . . . 5
4. Instantiation with Stateless autoconfiguration 6
4.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6
4.2. Initiation of the AAA process . . . . . . . . . . . . . . 8
4.3. Router initiation . . . . . . . . . . . . . . . . . . . . 8
4.3.1. Router initiated AAA - success . . . . . . . . . 9
4.3.2. Router initiated authentication - failure . . . . 9
4.3.3. Host does not support AAA . . . . . . . . . . . . 10
4.3.4. Router does not support AAA . . . . . . . . . . . 10
4.4. Host initiation . . . . . . . . . . . . . . . . . . . . . 10
4.5. Timing out . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. AAA teardown message . . . . . . . . . . . . . . . . . . 11
5. Instantiation with DHCPv6 11
5.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 11
5.2. Renewal of the AAA credentials . . . . . . . . . . . . . 12
5.3. DHCP client considerations . . . . . . . . . . . . . . . 12
5.4. DHCP relay considerations . . . . . . . . . . . . . . . . 13
5.5. DHCP server considerations . . . . . . . . . . . . . . . 13
6. Message formats 14
6.1. Stateless Autoconfiguration . . . . . . . . . . . . . . . 14
6.1.1. AAA Challenge/Response Option . . . . . . . . . . 14
6.1.2. NAI option . . . . . . . . . . . . . . . . . . . 15
6.1.3. AAA Credential option . . . . . . . . . . . . . . 15
6.1.4. AAA Reply option . . . . . . . . . . . . . . . . 16
6.1.5. Generalized AAA Key Reply option . . . . . . . . 16
6.1.6. AAA teardown message . . . . . . . . . . . . . . 16
6.1.7. Error Messages . . . . . . . . . . . . . . . . . 17
6.2. Stateful Autoconfiguration with DHCPv6 . . . . . . . . . 17
6.2.1. NAI extension . . . . . . . . . . . . . . . . . . 17
6.2.2. AAA-Credential extension . . . . . . . . . . . . 17
6.2.3. AAA-Challenge/Response extension . . . . . . . . 18
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page ii]
Internet Draft AAA for IPv6 20 November 2000
6.2.4. Generalized AAA Key Reply extension . . . . . . . 19
7. Open Issues and Discussion 19
7.1. Router solicitation or Neighbor solicitation . . . . . . 19
7.2. Packet Service Filter . . . . . . . . . . . . . . . . . . 19
7.3. Key distribution . . . . . . . . . . . . . . . . . . . . 19
7.4. Direct interaction with AAAL . . . . . . . . . . . . . . 20
7.5. Use of public key technology . . . . . . . . . . . . . . 20
References 21
Addresses 22
1. Introduction
This document proposes a way for IPv6 nodes (clients) to offer
credentials to a local AAA in order to be granted access to the local
network. Whereas for IPv4 it is not clear that routers and DHCP will
be equipped to handle such functions, we believe that it is more
efficient and thus reasonable to expect such access controls to be
exerted by IPv6 routers, possibly as part of performing their role as
DHCPv6 relays. DHCPv6 servers and routers are expected to work in
conjunction with AAA servers to determine whether or not the client's
credentials are valid.
Routers can exert such network access control by the device of
carefully controlling entries in their Neighbor Cache. If a device
does not supply verifiable credentials, then the router SHOULD NOT
forward packets to that device. Furthermore, such uncredentialed
devices should have no access (or perhaps only very limited access)
to the other network links adjacent to the router. Only in this
way can a new device be prevented from abusing network connectivity
before its authorization is complete.
2. Terminology
This document makes use of many terms defined in recent AAA
requirements documents (for example, [4]). The general framework
consists of nodes in the following general relationship:
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 1]
Internet Draft AAA for IPv6 20 November 2000
Local Domain Home Domain
+------------------------+ +--------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAL | | | | AAAH | |
| | +--------------------------+ | |
| +---+--+ | | +------+ |
| | \ +------+ | | |
| | \ | other| | +--------------+
+------+ | +---+--+ +------+| |
| | | | | | || | C = client
| C |- -|- -| A | | F |+ | A = attendant
| | | | | | | | F = packet filter
+------+ | +------+ +------+ | other = other AAA clients
| | AAAL = local authority
+------------------------+ AAAH = home authority
From a system point of view:
+--------------------------+ +-------------------+
| Router System | | AAA Server System |
+-------------+ | | | |
| Host System | | +--------+ +---------+ | | +--------------+ |
| | | | F | | A +-------+ AAAL | |
| | | +--------+ +---------+ | | | | |
| +------+ | | | | | | +------+-------+ |
| | C | | | +------+------+ | | | |
| +------+ | | Controlled | Uncontrolled| | | |
+------|------+ +------------|-------------+ | +------+-------+ |
| | | | AAAH | |
+-----------------------+ | | | |
| +--------------+ |
+-------------------+
The entities in the pictures above are defined as follows:
Host System
The host system is requesting access to the network. It is the
client on the host that is responsible for authentication and
authorization.
Client
The client is the entity whose authorization is checked. The
client resides on the host system that is requesting access to
the network.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 2]
Internet Draft AAA for IPv6 20 November 2000
Router System
The router provides network access to the host. Besides the
ordinary forwarding functionality on the router it provides AAA
functionality. The router provides access control by having an
attendant that is responsible for extracting the authentication
data and sending it to a AAA server. The router also has a
packet filter that grants access to the network.
Attendant
The server that extracts the client's NAI and AAA authorization
data from the protocol messages sending them to the AAAL for
verification. It is also responsible for extracting the
authorized services and authenticated IP address in the message
sent from the AAA server to the client. The attendant then
updates the packet filter with the authenticated IP-address and
adds an entry to the neighbor cache accordingly.
Packet filter
A packet filter/firewall/security gateway or equal
functionality filtering out unauthorized datagram traffic. The
filter updates its list when a user has been authenticated with
the appropriate IP address.
Controlled and uncontrolled access
Controlled access and uncontrolled access is associated with
each network interface.
AAAL
The AAA server in the foreign domain that provides local access
to the AAA infrastructure.
AAAH
The Home AAA server/domain which is able to authorize each of
its clients.
Other nodes
Other hosts that perform some function as a result of the
policy received from the AAAH, e.g. charging, QoS, etc.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 3]
Internet Draft AAA for IPv6 20 November 2000
AAA credential
Data provided by a client to the AAA in an authorization
request. For example, this can be a message authentication
code constructed using a secret shared between the host and the
AAAH.
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 [3].
3. General Framework
Using the terminology just introduced, in this section we describe
the general framework for our proposals.
The client accessing the network uses some protocol to solicit access
to the network it has been attached. Protocols considered in this
document include Stateless Autoconfiguration [8] and DHCPv6 [2], the
latter as an example of a stateful autoconfiguration service. We
also provide a comparison and discussion of the applicability to
DHCPv4.
Registration Requests [6] can be used by routers to inform hosts the
protocols and addresses used for AAA interactions.
A NAI [1] is often used to convey the user's identity, although IPv6
networks may well be constructed to determine the user's identity
based only on the user's IPv6 address. An AAA credential confirming
the identity claimed in the NAI to the AAA infrastructure is sent
separately from the NAI. Both the NAI and the AAA credential are
embedded in options or extensions of the protocol used in accessing
the network.
The attendant functionality is provided by the node receiving the
messages sent by the client. The functionality of the attendant
includes extracting the NAI and the AAA credential from the protocol
and sending them to the Local AAA server. The NAI and the AAA
credential are opaque to the attendant. Granting network access to a
client while waiting for a reply from the AAAL the attendant should
be a local policy decision. Based on the reply from the AAAL the
attendant either accepts or denies the request for network access.
The AAAL may also hand out keys with a finite lifetime to be used
for authentication subsequent protocol messages. The AAAL/AAAH may
also need to send information to the node. Such information will be
opaque to the attendant and must be sent to the client.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 4]
Internet Draft AAA for IPv6 20 November 2000
All traffic is by default never forwarded if the router has the AAA
service enabled. Every packet received on the interface is made
available to both the uncontrolled part and the controlled part.
The only thing that is forwarded over the uncontrolled access is
the AAA challenge response. Everything else is dropped. In the
controlled part all traffic and services that has been authenticated
and authorized is forwarded. Everything else is dropped.
3.1. Client requirements
The client is required to provide identification and credentials
to the local AAA infrastructure. The identification should enable
the AAAL to identify a suitable AAAH for carrying out all necessary
authorization steps. The identification MUST be a NAI. It MUST
identify the appropriate home domain to the attendant. It MAY also
identify the user to the attendant, although this is not necessary
(the user part of the NAI may be a pseudonym intelligible only to
AAAH).
3.2. Attendant requirements
The Attendant is required to:
- uniquely map clients to/from requests to the AAAL
- perform authentication of the protocol messages and to delete
expired authentication keys if the necessary keys have been
distributed to be used between the client and the attendant
3.3. AAAL requirements
The AAAL is required to:
- map AAA request/replies between the attendants and the AAA
infrastructure
3.4. Requirements for other nodes
[to be described]
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 5]
Internet Draft AAA for IPv6 20 November 2000
4. Instantiation with Stateless autoconfiguration
4.1. Protocol Overview
AAA authentication and authorization can be tied to IPv6 stateless
address autoconfiguration in IPv6 [8]. In this case the router acts
as an AAA attendant. The basic idea is to perform access control for
a host that request's access to the network. When a router enables
AAA service, the traffic is not forwarded by default. The router
only forwards traffic that comes from authenticated hosts.
The AAA service is enabled per interface on the router and there are
two access states associated with the router interface - uncontrolled
and controlled. An incoming packet to the router is verified in the
packet filter in the controlled access. If the packet is matched
with an entry in the packet filter then the packet is forwarded. The
only thing that is forwarded over the uncontrolled access are the AAA
challenge response messages. Everything else is dropped.
Normally, it is the attendant that is responsible for sending the
AAA challenge to the client and extracting the credentials from
the packet and send it to the AAA server for authentication and
authorization.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 6]
Internet Draft AAA for IPv6 20 November 2000
Host Router Attendant F AAAL AAAH
| RA + C | | | | |
|<--------| | | | |
|RS + C + CR + NAI| | | |
|---------|------>| | | |
| | | AAA Authentication + NAI | |
| | |----------------|---------------->| |
| | | | |- - - >|
| | | | | |
| | | | |< - - -|
| | |<---------------|-----------------| |
| | | Update F | | |
| | |--------------->| | |
| Update ND Cache | | |
| |<------| | | |
| | | | | |
|SRA + AAA Reply | | | |
|<--------|-------| | | |
| | | | | |
RA = Router Advertisement
C = AAA Challenge Response
CR = AAA Credential
RS = Router Solicitation
SRA = Solicited Router Advertisement
When an IPv6 host starts up or enter a new subnet, it will receive
a router advertisement with a AAA challenge option. The host will
reply with a router solicitation with options to carry the NAI and
AAA credentials. The attendant will extract AAA credentials and
forward them to AAAL for verification. If the verification is
successful, the AAA server will send back a AAA success message to
the attendant. The attendant will then add an entry for the host in
its neighbor cache and updates packet filter on the router.
The router MUST add an entry for a host in its neighbor cache and at
the same time update the packet filter with the authenticated host's
IP address when an AAA verification for the host has been successful.
When access control is enabled in the subnet all traffic that is
forwarded comes from authenticated hosts. This way unauthorized
hosts will not be able to receive incoming packets destined to them.
The router will then convey the result of the authorization to the
host by sending a solicited Router Advertisement with the AAA Reply
extension.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 7]
Internet Draft AAA for IPv6 20 November 2000
The IP address on the host is deprecated during the AAA
authentication and authorization. After AAA succeeds, the
router updates the packet filter with an entry having the
same lifetime as the authenticated ipv6-address on the host.
And the IP address is set to valid for a XXX lifetime.
There is no need for Duplicate Address Detection (DAD) since the
router controls all the access for the subnet in a centralized
manner. During the address management phase in neighbor discovery
the router also performs a AAA verification -- in order to avoid
duplicate addresses, the attendant performs a check in the packet
filter and if it finds a match then DAD fails and an error message is
sent back to the host.
It is also possible to terminate valid sessions. To terminate
a session, the attendant clears the packet filter and sends a
termination message to the host which invalidates the IP address. A
typical scenario for termination would be in a pre-paid service when
the pre-paid amount is used up.
4.2. Initiation of the AAA process
The AAA process can be initiated either from the host or from the
router. The router interface for the subnetwork has to enable the
AAA service in order to achieve access control. The authentication
data is always sent to the uncontrolled part of the interface and
then then it is up to the attendant to extract the authentication
data and send it to a AAA server.
4.3. Router initiation
The router initiates the AAA process by sending router advertisements
that includes a AAA challenge option. The host responds to the AAA
challenge by sending a response using the AAA credential option and
possibly an NAI option. The router attendant then extracts the NAI
and credentials and send them to a AAA server. The verification in
the AAA server can result in either success or failure.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 8]
Internet Draft AAA for IPv6 20 November 2000
4.3.1. Router initiated AAA - success
+--------+ +-----------+ +--------+
| | | Attendant | | AAA |
| Client | | | | Server |
+--------+ +-----------+ +--------+
<------------- AAA Challenge
AAA Response -------------- - - - - - - - - - >
<------------------- - - - - - - - AAA Success
Router initiated AAA process is shown above. When the router
receives the AAA success message the attendant is responsible for
- adding an entry in the neighbor cache
- updating the packet filter with the authenticated host's IPv6
address
The host is then authenticated.
// Comment: What about mention anything that the address is
deprecated in the host until the AAA succeeds?
4.3.2. Router initiated authentication - failure
+--------+ +-----------+ +--------+
| | | Attendant | | AAA |
| Client | | | | Server |
+--------+ +-----------+ +--------+
<----------------- AAA Challenge
AAA Response ----------- - - - - - - - - - >
<-------------------- - - - - - - - AAA Failure
Upon a AAA failure nothing happens in the router. The attendant
receives a AAA failure option message from the AAA server. The
attendant is responsible for extracting the information in the
failure message and informing the host that the AAA verification
failed and for updating the packet filter to block the host that
failed.
//Comment: Should we add a "special" state in the neighbor
discovery cache with something like similar to deprecated
state that is not authenticated... How should the failure
message look like?
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 9]
Internet Draft AAA for IPv6 20 November 2000
4.3.3. Host does not support AAA
+--------+ +-----------+ +--------+
| AAA | | Attendant | | AAA |
| Client | | | | Server |
+--------+ +-----------+ +--------+
<--------------- AAA challenge
<--------------- AAA challenge
<--------------- AAA challenge
(No response
from client...)
The host remains unauthorized and can never access an outside the AAA
controlled network.
4.3.4. Router does not support AAA
+--------+ +-----------+ +--------+
| | | Attendant | | AAA |
| Client | | | | Server |
+--------+ +-----------+ +--------+
If the router does not support AAA, the host is autoconfigured via
usual neighbor discovery. This can happen if a host roams into a
non-AAA capable network.
4.4. Host initiation
[to be described]
4.5. Timing out
If the router is close to time out its entry in the neighbor cache it
will re-issue a AAA challenge against the host. The host will send
a challenge response and an usual AAA authentication is done and if
it is a AAA success, the attendant then updates the timers in the
neighbor discovery cache.
// Comment: Should we have a seq no so that we can separate
the initial AAA authentication from the following ones.
What do you think?
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 10]
Internet Draft AAA for IPv6 20 November 2000
What should happen when the host times out? What Lifetimes
should we have on the different entries in the attendant?
How do we sync between address lifetime and authorization
lifetime etc... How do we update the timers according to
the lifetime in the packet filter
4.6. AAA teardown message
The AAA teardown message is sent from the attendant to invalidate
the host IP address. This is useful when an operator wants to shut
down an interface or in the case of a pre-paid service of a host that
becomes invalid.
When the host receives this message it clears its neighbor cache.
The authenticated IP address is sent with a zero lifetime. A
teardown message MUST be authenticated with an AH header.
5. Instantiation with DHCPv6
5.1. Protocol Overview
When a DHCP client needs to allocate an IPv6 address, it will first
send DHCP Solicit messages soliciting for the DHCP servers serving
the network. In the Solicit message the client MAY identify itself
using the NAI extension. The DHCP servers receiving the solicitation
reply by sending DHCP Advertise messages containing an AAA-Challenge
extension to the client. The value of the AAA-Challenge extension is
used as a challenge by the client.
After receiving the DHCP Advertise the DHCP client computes a
response to the challenge and creates a DHCP Request message that is
to be sent to the DHCP server. The DHCP Request message contains an
AAA-Challenge/Response extension, a NAI extension with the client's
NAI and an AAA-Credential extension.
The DHCP server receiving the DHCP Request extracts the NAI, the
response to the challenge and the AAA credential from the DHCP
message and sends these to the AAAL server. The AAAL uses the AAA
network to forward the AAA message to the AAAH. The AAAH processes
the AAA message and forms a reply to the AAAL. The reply may contain
keys, policy information, etc. targeted to the AAAL, the DHCP server
and/or the DHCP client. The AAAL identifies which information is
given to the DHCP server (e.g. keys) and which are to be applied
locally to the network (e.g. policy). The data that is sent to the
DHCP client (e.g. keys, policy, etc.) is treated as opaque by the
AAAL and DHCP servers and forwarded to the DHCP client.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 11]
Internet Draft AAA for IPv6 20 November 2000
Based on the reply from the AAAL, the DHCP server forms a DHCP Reply
message either accepting or denying the registration attempt. The
opaque AAA data received from the AAAL is inserted in an extension in
the DHCP Reply message.
A session set up using DHCP follows the guidelines specified by the
DHCP protocol when the session is ended.
DHCP DHCP
Host relay server F AAAL AAAH
| | | | | |
| DS + NAI | | | |
|--------|------->| | | |
| DA + C | | | |
|<-------|--------| | | |
|DR + C + CR + NAI| AAA message containing the | |
|--------|------->| values sent in the C, CR and NAI | |
| |--------------------------------->| |
| | | | |- - - >|
| | | | |
| | | AAA message | |< - - -|
| |<---------------------------------| |
| DRep + KR? | | Update F | |
|<----------------| |<----------------| |
| | | | | |
| | | | |
| | | | | |
| | | | |
| | | | | |
DS = DHCP Solicit
DA = DHCP Advertise
DR = DHCP Request
DRep = DHCP Reply
C = AAA Challenge/Response
CR = AAA Credential
KR = AAA Key Reply
5.2. Renewal of the AAA credentials
5.3. DHCP client considerations
A DHCP client sending a DHCP Solicit MAY include its NAI in the
message. If a DHCP Advertise with an AAA-Challenge/Reply extension
is received the client has to computes a reply. How the reply is
computed is not yet defined.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 12]
Internet Draft AAA for IPv6 20 November 2000
The DHCP client sends the needed credentials, challenge reply and
its NAI in the DHCP Request message. A NAI extension identifying
the client MUST be included if the DHCP Request contains an
AAA-Credential extension. If there exists and DHCP security
association between the DHCP client and the DHCP server, the DHCP
Request message MUST be protected by that security association. The
security association could for example have been generated at the
time of the previous request of the address.
Upon receiving the DHCP Reply the DHCP client has to be ready for the
following to happen:
- The 'status' field of the DHCP Reply indicates that the address
has been successfully leased to the DHCP client. If the DHCP
Reply is secured by an authentication extension, the correctness
of the authentication extension is checked. If the security
association for the authentication extension does not exist, the
DHCP client will first look for an AAA Key Reply extension for
keys needed to create the security association. If such key
information is present, the client creates the needed security
association and retries to verify the correctness of the message.
- The 'status' field indicates success but no AAA reply extensions
are present. The DHCP client will start using the leased address
as normal.
- The 'status' field indicates that the AAA authorizations has
failed. The DHCP client is unable to gain access in the network.
- The 'status' field indicates any other error condition. The DHCP
client continues according to the DHCP protocol.
5.4. DHCP relay considerations
A DHCP relay receiving any AAA extensions MUST forward these
extensions unaltered between the client and the server.
5.5. DHCP server considerations
A DHCP server MAY add an AAA-Challenge extension to the DHCP
Advertise message. The challenge sent to the client MAY depend on
the NAI extension in the DHCP Solicitation message but it MAY also be
derived independent of the client's NAI.
Depending on the local policy and/or the capability of the DHCP
server, the DHCP server may choose to ignore the AAA information
contained in the NAI, AAA-Credential and both Challenge/Response
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 13]
Internet Draft AAA for IPv6 20 November 2000
extensions. In this case the DHCP server uses the extensions only
when verifying the possible authentication of the DHCP message. In
general a DHCP server receiving the NAI and AAA extensions SHOULD
extract and forward them to the AAAL.
It is assumed that the AAA processing will require time and
computational power, which would be in vain if some of the
information contained in the message is found to be incorrect.
Therefore, prior to sending the information contained in the AAA
extensions to the AAAL the DHCP server checks the correctness of the
DHCP Request message.
If the AAAL sends e.g. keys back to the DHCP client, the DHCP server
MUST include these in an AAA Key Reply extension in the DHCP Reply
message. The DHCP server will indicate an AAA failure reported by
the AAAL by setting the 'status' field in the DHCP Reply message to
'AAA Failed Authentication', which is an yet undefined value. The
DHCP server will also add the proper authentication extension to the
DHCP Reply and any further messages, if keys have been distributed by
the AAA to be used between the client and the server.
6. Message formats
6.1. Stateless Autoconfiguration
6.1.1. AAA Challenge/Response Option
The AAA challenge/response option is applicable to Router
Advertisements and to Router Solicitations.
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 = TBD | Length | Challenge ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The Type field identifies the option as being an AAA
challenge option and has a value of TBD.
Length The Length field gives the length measured in octets of
this option, including the Type and Length fields.
Challenge This field contains a challenge when the option is sent
as part of an Router Advertisement and a reply when the
option is sent as part of an Router Solicitation.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 14]
Internet Draft AAA for IPv6 20 November 2000
6.1.2. NAI option
The NAI option is applicable to Router Solicitation. It is used to
convey the NAI of the user/host to the AAAL.
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 = TBD | Length | NAI...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The Type field identifies the option as being a NAI option
and has a value of TBD.
Length The Length field gives the length measured in octets of
this extension, including the Type and Length fields.
NAI This field contains a NAI formatted according to
RFC2486 [1].
6.1.3. AAA Credential option
The AAA Credential option MUST be accompanied by a NAI option. AAA
Credential option is applicable to Router Solicitation. It is
used to transport a suitable AAA-Credential which AAAL can use to
authorize the access of the entity identified by the accompanying NAI
extension.
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 = TBD | Length | AAA-Credential...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The Type field identifies the option as being a
AAA credential option and has a yet undefined
value.
Length The Length field gives the length measured in
octets of this extension including the Type and
Length fields.
AAA-Credential Host credential to be forwarded to AAAL by the
router.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 15]
Internet Draft AAA for IPv6 20 November 2000
6.1.4. AAA Reply option
The AAA Reply option to solicited Router Advertisement is used
by the router to convey the result of the authorization process
(received from AAAL) to the host. This extension MUST NOT be used
with unsolicited Router Advertisements.
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=TBD | Length | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA Challenge ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The Type field identifies the option as being the AAA
reply code and has a yet undefined value.
Length Length of the option (If there is no AAA challenge, the
length should be 4)
Code 16-bit unsigned integer code indicating the result of the
AAA authorization process. [0 = success, other error
values to be defined]
AAA Challenge Optional challenge sent by AAAH to the client.
6.1.5. Generalized AAA Key Reply option
[to be described]
Should we defined a generalized AAA Key Reply option in the
style of [7] that can carry encoded keys back to the host
and the host can (somehow) insert them into the IPSec SA
database?
6.1.6. AAA teardown message
The AAA teardown message is sent when a host do a graceful shutdown.
When the router receives this message it invalidates the authorized
entries in the service block and in the packet filter. The
authorized entries are sent with a zero lifetime. A teardown message
MUST be authenticated with an AH header.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 16]
Internet Draft AAA for IPv6 20 November 2000
6.1.7. Error Messages
TBD
6.2. Stateful Autoconfiguration with DHCPv6
6.2.1. NAI extension
A DHCP client adds the NAI extension to its DHCP Request whenever it
needs to transmit its NAI to the local AAA service.
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 = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI...
+-+-+-+-+-+-
Type The Type field identifies the extension as being a
NAI extension and has a value of TBD.
Length The Length field gives the length measured in
octets of this extension, not including the Type
and Length fields.
NAI This field contains a NAI formatted according to
RFC2486 [1].
6.2.2. AAA-Credential extension
The AAA-Credential extension contains AAA credential that the DHCP
client wants to present to the AAA domain. The AAA-Credential
extension is also used by the DHCP server forwarding AAA credential
destined to the DHCP client.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 17]
Internet Draft AAA for IPv6 20 November 2000
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 = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA-Credential...
+-+-+-+-+-+-+-+-+-
Type The Type field identifies the extension as
being an AAA-Credential extension and has a yet
undefined value.
Length The Length field gives the length measured in
octets of this extension not including the Type
and Length fields.
AAA-Credential Host credential to be forwarded to AAAL by the
DHCPv6 server.
6.2.3. AAA-Challenge/Response extension
When sent in a DHCP Advertise message the AAA-Challenge/Response
extension contains a challenge sent to the client. When the
AAA-Challenge/Response extension is present in a DHCP Request message
it contains a Response to the previous challenge.
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 = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA-Challenge/Response...
+-+-+-+-+-+-+-+-+-
Type The Type field identifies the extension as being
an AAA-Challenge/Response extension and has a yet
undefined value.
Length The Length field gives the length measured in
octets of this extension not including the Type
and Length fields.
AAA-Challenge/Response A challenge when sent to the client or a
response when sent to the server.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 18]
Internet Draft AAA for IPv6 20 November 2000
6.2.4. Generalized AAA Key Reply extension
[to be described]
Should we defined a generalized AAA Key Reply extension in
the style of [7] that can carry encoded keys back to the
host and the host can (somehow) insert them into the IPSec
SA database?
7. Open Issues and Discussion
7.1. Router solicitation or Neighbor solicitation
We have suggested using Router solicitation to carry the AAA
credential information from the host to the attendant(See Section
4.1). Router solicitations need to be multicast. The advantage
in using Router Solicitation is that the host always sends the AAA
credentials to the same address (the all-routers multicast address).
The disadvantage is the cost of multicast.
An alternative is to use Neighbor solicitation instead. In order to
do this, the host should know the specific address of the Attendant.
This information may be carried in an option of Router Advertisement.
One suggested possibility is to use Router Solicitation for the first
AAA run, and Neighbor solicitation for the subsequent ones.
7.2. Packet Service Filter
There is also a future work to determine how services can be
updated dynamically based on the authorized services. A typical
service filter will permit/deny a filter rule based on upper layer
information for the authenticated IP address.
The attendant could prepare an ACL with service filters based on the
AAA response for the authenticated services for the different UDP/TCP
ports.
7.3. Key distribution
The AAA process must result in session keys distributed to the client
as well as the router(s) in the subnet. These keys must then be
added to the IPSec security association database. We need to explain
how the keys are distributed (see the Generalized AAA Key Reply
option) and how the security associations are set up.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 19]
Internet Draft AAA for IPv6 20 November 2000
7.4. Direct interaction with AAAL
An alternative approach would be to require that IPv6 nodes support
AAA client functionality. Router advertisements will contain an
extension indicating the IP address of the AAA server in a subnet.
The IPv6 node should send its credentials directly to the AAA server.
7.5. Use of public key technology
At some point, it may be feasible/necessary to use digital signatures
for client authorization. The sizes of Router/Neighbor solicitation
options are limited by the one octet length field. This may make
it necessary to invent some sort of a container mechanism so that
several options can be used together to carry digital signatures or
certificates that are longer than 256 bytes.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 20]
Internet Draft AAA for IPv6 20 November 2000
References
[1] B. Aboba and M. Beadles. The Network Access Identifier. Request
for Comments (Proposed Standard) 2486, Internet Engineering Task
Force, January 1999.
[2] J. Bound and C. Perkins. Dynamic Host Configuration Protocol for
IPv6 (DHCPv6). Internet Draft, Internet Engineering Task Force,
February 1999. Work in progress.
[3] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[4] S. Glass, T. Hiller, S. Jacobs, and C. Perkins. Mobile IP
Authentication, Authorization, and Accounting Requirements.
Internet Draft, Internet Engineering Task Force.
draft-ietf-mobileip-aaa-reqs-01.txt, January 2000. Work in
progress.
[5] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461,
Internet Engineering Task Force, December 1998.
[6] E. Nordmark. IPv6 hooks for AAA and "host routing". Internet
Draft, Internet Engineering Task Force, March 2000.
[7] C. Perkins and P. Calhoun. Generalized Key Distribution
Extensions for Mobile IP.
draft-ietf-mobileip-gen-key-00.txt, February 2000. (work in
progress).
[8] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. Request for Comments (Draft Standard)
2462, Internet Engineering Task Force, December 1998.
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 21]
Internet Draft AAA for IPv6 20 November 2000
Addresses
The working group can be contacted via the current chairs:
Stephen E. Deering Robert M. Hinden
Cisco Systems, Inc. Nokia
170 West Tasman Drive 313 Fairchild Drive
San Jose, CA 95134-1706 Mountain View, CA 94303
USA USA
Phone: +1 408 527 8213 Phone: +1 650 625-2004
Fax: +1 408 527 8254 Fax: +1 650 625-xxxx
EMail: deering@cisco.com EMail: hinden@iprg.nokia.com
Questions about this memo can also be directed to the authors:
N. Asokan Thomas Eklund
Nokia Research Center Xelerated Networks
P.O. Box 407 Regeringsgatan 67
FIN-00045 NOKIA GROUP
Helsinki 103 86 Stockholm
Finland Sweden
Phone: +358 40 743 1961 Phone: +46 8 50625753
E-mail: n.asokan@nokia.com E-mail: thomas.eklund@xelerated.com
Fax: +358 9 4376 6852 Fax: +46 8 54553211
Patrik Flykt Charles E. Perkins
Nokia Networks Communications Systems Lab
P.O. Box 321 Nokia Research Center
FIN-00045 NOKIA GROUP 313 Fairchild Drive
Mountain View, California 94043
Finland USA
Phone: +358 9 511 68072 Phone: +1-650 625-2986
E-mail: patrik.flykt@nokia.com EMail: charliep@iprg.nokia.com
Fax: +358 9 511 68080 Fax: +1 650 625-2502
Asokan, Eklund, Flykt, Perkins Expires 20 May 2001 [Page 22]