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-ietf-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]