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]