Mobile IP Working Group N. Asokan
INTERNET DRAFT Patrik Flykt
10 March 2000 Charles E. Perkins
Nokia Research Center
Thomas Eklund
SwitchCore
AAA for IPv6 Network Access
draft-perkins-aaav6-00.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
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.
Asokan, Eklund, Flykt, Perkins Expires 10 September 2000 [Page i]
Internet Draft AAA for IPv6 10 March 2000
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Terminology 2
3. General Framework 3
3.1. Client requirements . . . . . . . . . . . . . . . . . . . 4
3.2. Attendant requirements . . . . . . . . . . . . . . . . . 4
3.3. AAAL requirements . . . . . . . . . . . . . . . . . . . . 4
3.4. Requirements for other nodes . . . . . . . . . . . . . . 5
4. Instantiation with Stateless autoconfiguration 5
4.1. Message formats . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. NAI option . . . . . . . . . . . . . . . . . . . 5
4.1.2. AAA Credential option . . . . . . . . . . . . . . 6
4.1.3. AAA Reply option . . . . . . . . . . . . . . . . 6
4.2. Router considerations . . . . . . . . . . . . . . . . . . 7
4.3. Host considerations . . . . . . . . . . . . . . . . . . . 7
5. Instantiation with DHCPv6 7
5.1. MN-NAI extension . . . . . . . . . . . . . . . . . . . . 8
5.2. MN-AAA extension . . . . . . . . . . . . . . . . . . . . 8
5.3. DHCP client considerations . . . . . . . . . . . . . . . 9
5.4. DHCP relay considerations . . . . . . . . . . . . . . . . 9
5.5. DHCP server considerations . . . . . . . . . . . . . . . 9
5.6. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Packet filtering functions 10
7. Discussion 11
7.1. Direct interaction with AAAL . . . . . . . . . . . . . . 11
References 12
Addresses 13
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
Asokan, Eklund, Flykt, Perkins Expires 10 September 2000 [Page 1]
Internet Draft AAA for IPv6 10 March 2000
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 the following nodes:
Local Domain Home Domain
+------------------------+ +--------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAL | | | | AAAH | |
| | +--------------------------+ | |
| +---+--+ | | +------+ |
| | \ +------+ | | |
| | \ | other| | +--------------+
+------+ | +---+--+ +------+| |
| | | | | | || | C = client
| C |- -|- -| A | | F |+ | A = attendant
| | | | | | | | F = packet filter
+------+ | +------+ +------+ | other = other nodes
| | AAAL = local authority
+------------------------+ AAAH = home authority
Client
The host requesting access to the network.
Asokan, Eklund, Flykt, Perkins Expires 10 September 2000 [Page 2]
Internet Draft AAA for IPv6 10 March 2000
Attendant
The server that extracts the client's NAI and AAA authorization
data from the protocol messages sending them to the AAAL for
verification.
Packet filter
A packet filter/firewall/security gateway (?) or equal
functionality filtering out unauthorized datagram traffic.
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.
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 [5] 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.
A NAI [1] is typically used to convey the user's identity. Data
confirming the authorization of the identity claimed in the NAI to
the AAA infrastructure is sent sent separately from the NAI. Both the
NAI and the AAA data are embedded in extensions of the protocol used
in accessing the network.
Asokan, Eklund, Flykt, Perkins Expires 10 September 2000 [Page 3]
Internet Draft AAA for IPv6 10 March 2000
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 data from the protocol and
sending them to the Local AAA server. The NAI and the AAA data
will most likely be opaque to the attendant, the attendant should
therefore not try to decipher these. 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.
// Comment: Thomas, let not the above description confuse
you about writing the other Stateless Autoconfiguration
scenario :-).
// Comment: a MN-AAA extension used for authorization/
authentication to the AAA system. Use the AAA extension
in both directions, since AAA may want to send some
"policy"/key information to the host/client?
The AAAL may also control other nodes in order to satisfy the policy
requirements demanded by the AAA infrastructure, especially the AAAH.
These include for example charging, QoS, datagram filtering, etc.
// Comment: How do we distinguish between sending the AAA
message in the Router Solicitation and using DHCPv6 to do
the same? Local policy?
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 will typically take the form
of a NAI, thus identifying both the user and the appropriate home
domain.
3.2. Attendant requirements
The Attendant is required to:
- uniquely map clients to/from requests to the AAAL
Asokan, Eklund, Flykt, Perkins Expires 10 September 2000 [Page 4]
Internet Draft AAA for IPv6 10 March 2000
- 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
4. Instantiation with Stateless autoconfiguration
AAA authorization can be tied to IPv6 stateless address
autoconfiguration. In this case the router acts as an AAA attendant.
The basic idea is to make the router add an entry for a host in
its neighbor cache only if AAA authorization for the host has been
successful. When an IPv6 host starts up in a subnet, it sends
a router solicitation with extensions to carry the NAI and AAA
credentials. The router will extract AAA credentials and forward
them to AAAL. If authorization is successful, the router can add an
entry for the host in its neighbor cache. 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.
// Comment: Should the router include a bit in unsolicited
router advertisements stating that AAA authorization is
necessary?
4.1. Message formats
4.1.1. NAI option
The NAI option to Router Solicitation is used to convey the NAI of
the user/host to the AAAL.
Asokan, Eklund, Flykt, Perkins Expires 10 September 2000 [Page 5]
Internet Draft AAA for IPv6 10 March 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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].
4.1.2. AAA Credential option
The AAA Credential option MUST be accompanied by a NAI extension.
AAA Credential option to Router Soliciation 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 Credential to be forwarded to AAAL by the router.
4.1.3. AAA Reply option
The AAA Reply option to solicited Router Advertisement is used
by the router to convey the result of the authorization process
Asokan, Eklund, Flykt, Perkins Expires 10 September 2000 [Page 6]
Internet Draft AAA for IPv6 10 March 2000
(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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The Type field identifies the option as being the AAA
reply code and has a yet undefined value.
Length 4
Code 16-bit unsigned integer code indicating the result of the
AAA authorization process. [0 = success, other error
values to be defined]
4.2. Router considerations
If a router receives a Router Solicitation with the AAA Credential
option, it must send back solicited Router Advertisement with the AAA
Reply option.
4.3. Host considerations
[TODO]
5. Instantiation with DHCPv6
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. The DHCP servers receiving the solicitation will reply
by sending DHCP Advertise messages to the client.
// Comment: Should the DHCP server include a bit stating
that AAA authorization is necessary?
If AAA authorization is needed for the network, the DHCP client
will add an MN-NAI extension containing the DHCP client's NAI and a
MN-AAA extension containing AAA data to the DHCP Request message.
The DHCP server receiving the DHCP Request extracts both the NAI and
the AAA data from the extensions and sends these to the AAAL. The
AAAL uses the AAA network to forward the AAA data to the AAAH. The
AAAH will processes the AAA data and form a reply to the AAAL. The
Asokan, Eklund, Flykt, Perkins Expires 10 September 2000 [Page 7]
Internet Draft AAA for IPv6 10 March 2000
reply may contain keys, policy information, etc. targeted to the
AAAL, the DHCP server and the DHCP client. The AAAL will identify
which information should be given to the DHCP server (e.g. keys) and
which should be applied locally to the network (e.g. policy). The
data that the AAAH sends to the DHCP client (e.g. keys, policy) will
be treated as opaque and forwarded by the AAAL to the DHCP server.
Based on the reply from the AAAL, the DHCP server will create a DHCP
Reply either accepting or denying the address lease. The opaque AAA
data received from the AAAL is inserted in the MN-AAA extension in
the DHCP Reply message.
// Comment: Should keys have their own extensions instead
of reusing the MN-AAA extension?
// Comment: What is the visible effect of router control
over Neighbor Cache entries upon reception of DHCP Reply?
5.1. MN-NAI extension
A DHCP client adds the MN-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
MN-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].
5.2. MN-AAA extension
The MN-AAA extension contains AAA data that the DHCP client wants to
present to the AAA domain. The MN-AAA extension is also used by the
DHCP server forwarding AAA data destined to the DHCP client.
Asokan, Eklund, Flykt, Perkins Expires 10 September 2000 [Page 8]
Internet Draft AAA for IPv6 10 March 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 data...
+-+-+-+-+-+-+-+-+-
Type The Type field identifies the extension as being
an MN-AAA 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 data Data sent to/from the AAA domain.
5.3. DHCP client considerations
When the DHCP client solicits for an address in a network that
requires AAA authorization, the DHCP client sends the needed
authorization data in a MN-AAA extension in the DHCP Request message.
A MN-NAI extension identifying the client MUST be included in the
DHCP Request containing the MN-AAA 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 may 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 examine the MN-AAA extension for
keys, etc. needed to create the security association. If such
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 MN-AAA extension is
present. The DHCP client will start using the leased address as
normal.
Asokan, Eklund, Flykt, Perkins Expires 10 September 2000 [Page 9]
Internet Draft AAA for IPv6 10 March 2000
- 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.
// Comment: These "bullet points" probably need to evolve
more to an exact "flow chart"?
5.4. DHCP relay considerations
A DHCP relay receiving a MN-NAI or a MN-AAA extension MUST forward
these extensions unaltered between the client and the server.
5.5. DHCP server considerations
// Comment: Setting an "AAA" bit in the DHCP Advertise
message?
A DHCP server receiving the MN-AAA and MN-NAI extensions SHOULD
extract and forward both the NAI and the AAA data to the AAAL.
Depending on the local policy and/or the capability of the DHCP
server, the DHCP server may choose to ignore the information
contained in the MN-NAI and MN-AAA extensions. In this case the
server may skip the extensions, and only using the extensions when
verifying a possible authentication extension for the message.
Prior to sending the NAI and the AAA data to the AAAL, the DHCP
server may check the correctness of the rest of the message. It is
assumed that the AAA processing will require time and computational
power, which would be in vain if some of the information contained
later on in the message would be incorrect.
If the AAA system sends data back to the DHCP client, the DHCP
server MUST include this data in an MN-AAA extension in the DHCP
Reply message. If there is no such data present, the DHCP server
will not add a MN-AAA extension to 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 has the value TBD. The AAAL might
also distribute keys together with a lifetime to be used in the
authentication of further DHCP messages. In this case the DHCP
server will add the proper authentication extension to the DHCP Reply
and any further messages.
Asokan, Eklund, Flykt, Perkins Expires 10 September 2000 [Page 10]
Internet Draft AAA for IPv6 10 March 2000
5.6. DHCPv4
As DHCPv4 is very similar to DHCPv6, the same messaging sequence can
be applied to DHCPv4. The DHCPv6 Solicit message maps to the DHCPv4
Discover message, the DHCPv6 Advertise to the DHCPv4 Offer message,
the DHCPv6 Request to the DHCPv4 Request message and the DHCPv6
Reply to the DHCPv4 Ack message. However, there is one fundamental
difference: the length of an DHCPv4 extension cannot exceed 255
octets. There exists a draft describing a solution to the length
problem, which is a real problem only if either one of the extensions
need sizes longer than 255 octets.
6. Packet filtering functions
// Comment: Here we put the discussion of packet
filering and security gateways and their respective
benefits/drawbacks.
7. Discussion
// Comment: Here we put unresolved and alternative
scenarios.
7.1. 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.
Asokan, Eklund, Flykt, Perkins Expires 10 September 2000 [Page 11]
Internet Draft AAA for IPv6 10 March 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] 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 10 September 2000 [Page 12]
Internet Draft AAA for IPv6 10 March 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
Communications Systems Lab SE-115 74
Nokia Research Center Positionen 153, Hangvgen 19
Ruoholahti SwitchCore i Stockholm AB
Helsinki Stockholm
Finland Sweden
Phone: +358 40 743 1961 Phone: +46 8 5630 5815
E-mail: n.asokan@nokia.com E-mail: thomas.eklund@switchcore.com
Fax: +358 94 376 6852 Fax: +46 8 5630 5801
Patrik Flykt Charles E. Perkins
Communications Systems Lab Communications Systems Lab
Nokia Research Center Nokia Research Center
Valimo 9 313 Fairchild Drive
Helsinki Mountain View, California 94043
Finland USA
Phone: +358 95 11 68072 Phone: +1-650 625-2986
E-mail: patrik.flykt@nokia.com EMail: charliep@iprg.nokia.com
Fax: +358 95 11 68080 Fax: +1 650 625-2502
Asokan, Eklund, Flykt, Perkins Expires 10 September 2000 [Page 13]