IPng Working Group N. Asokan INTERNET DRAFT Patrik Flykt 5 January 2000 Charles E. Perkins Nokia Thomas Eklund Xelerated Networks AAA for IPv6 Network Access draft-perkins-aaav6-02.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 5 July 2001 [Page i] Internet Draft AAA for IPv6 5 January 2000 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Terminology 1 3. General Framework 3 3.1. Protocol Description . . . . . . . . . . . . . . . . . . 3 3.2. Client Identifier . . . . . . . . . . . . . . . . . . . . 5 3.3. Replay Protection . . . . . . . . . . . . . . . . . . . . 5 3.4. AAA Credential . . . . . . . . . . . . . . . . . . . . . 6 4. Instantiation with Stateless Address Autoconfiguration 6 4.1. Structure of Protocol Messages . . . . . . . . . . . . . 6 4.1.1. AAA Protocol Message types . . . . . . . . . . . 7 4.1.2. AAA Protocol Message options . . . . . . . . . . 7 4.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Basic operation . . . . . . . . . . . . . . . . . 8 4.2.2. Challenge Request . . . . . . . . . . . . . . . . 10 4.2.3. Termination . . . . . . . . . . . . . . . . . . . 10 4.3. Initiation of the AAA Process . . . . . . . . . . . . . . 11 5. Instantiation with Mobile IPv6 11 6. Instantiation with DHCPv6 11 6.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 11 6.2. Renewal of the AAA credentials . . . . . . . . . . . . . 13 6.3. DHCP Client Considerations . . . . . . . . . . . . . . . 13 6.4. DHCP Relay Considerations . . . . . . . . . . . . . . . . 14 6.5. DHCP Server Considerations . . . . . . . . . . . . . . . 14 7. Message Formats for Stateless Address Autoconfiguration 15 7.1. AAA Challenge Option . . . . . . . . . . . . . . . . . . 15 7.2. AAA Protocol Messages . . . . . . . . . . . . . . . . . . 15 7.3. AAA Protocol Message Options . . . . . . . . . . . . . . 17 7.3.1. Client Identifier option . . . . . . . . . . . . 17 7.3.2. Security Data . . . . . . . . . . . . . . . . . . 18 7.3.3. Challenge . . . . . . . . . . . . . . . . . . . . 19 7.3.4. Generalized Key Reply . . . . . . . . . . . . . . 19 7.3.5. Timestamp . . . . . . . . . . . . . . . . . . . . 21 7.3.6. IPv6 Address . . . . . . . . . . . . . . . . . . 21 7.3.7. Lifetime . . . . . . . . . . . . . . . . . . . . 22 7.3.8. Embedded Data . . . . . . . . . . . . . . . . . . 23 Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page ii] Internet Draft AAA for IPv6 5 January 2000 8. Message Formats for Stateful Address Autoconfiguration with DHCPv6 24 8.1. NAI Extension . . . . . . . . . . . . . . . . . . . . . . 24 8.2. AAA-Credential Extension . . . . . . . . . . . . . . . . 24 8.3. AAA-Challenge/Response Extension . . . . . . . . . . . . 25 8.4. Generalized AAA Key Reply Extension . . . . . . . . . . . 26 9. Security Considerations 26 10. Open Issues and Discussion 26 10.1. Packet Service Filter . . . . . . . . . . . . . . . . . . 26 10.2. Use of Destination Options . . . . . . . . . . . . . . . 26 References 27 Addresses 28 1. Introduction This document proposes a way for IPv6 nodes (clients) to offer credentials to a local AAA server 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 packet filter and Neighbor Cache. If a host does not supply verifiable credentials, then the router SHOULD NOT forward packets to that host. 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 host 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 5 July 2001 [Page 1] Internet Draft AAA for IPv6 5 January 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 | +-------------+ | | | Infrastructure | | 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 the node requesting access to the network. Client: The client is the entity whose authorization is checked. The client resides on the host system. Router System: The router is the node that provides network access to the host. In addition to the usual packet forwarding functionality, the router system typically consists of other functional blocks like the attendant and the packet filter. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 2] Internet Draft AAA for IPv6 5 January 2000 Attendant: The attendant is the entity that extracts identification and authorization data sent by the client and forwards them to AAAL for verification. It is also responsible for making the necessary configuration updates (e.g., to the packet filter, and the router's neighbor cache) so that only authorized clients can access the network. Packet filter: A packet filter/firewall/security gateway is the entity responsible for disallowing unauthorized datagram traffic. When a client is authorized, the access control list of the filter is updated with the corresponding host's IP address(es). Controlled and uncontrolled access: Each network interface of the router can be configured to provide AAA services. When an interface is so configured, all transiting packets are subject to controlled access. If a packet does not pass access control, but is an AAA message addressed to the router, it is given to the Attendant in the uncontrolled access part. AAAL: The AAA server in the foreign domain that mediates local access to the AAA infrastructure. AAAH: The AAA server in the home 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 AAAH, e.g. accounting, QoS, etc. 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 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. 3.1. Protocol Description The client solicits access to the network in conjunction with some protocol. Protocols considered in this document include Stateless Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 3] Internet Draft AAA for IPv6 5 January 2000 Address Autoconfiguration [7] DHCPv6 [2], as an example of a stateful autoconfiguration service, and Mobile IPv6. If the router has AAA service enabled, a packet received on the interface is made available to the controlled part. The controlled part will only forward traffic that corresponds to an authorized host. All other packets will be dropped except for upstream AAA authorization protocol packets (sent by the host to the router). Such packets are made available to the attendant in the uncontrolled part. The attendant may extract the relevant AAA data and forward them to AAAL. The overall protocol is depicted below. Router +.......................+ Host . UCP CP . AAAL AAAH | LC . | | . | | |<--------------------| | . | | |AAA Req: LC,RPI,ID,CR| | . | | |-------------------->| | . | | | . | AHR | . | | | . |- - - - - - - - |- - - - - - - - >| AHR | | . | | . |- - - >| | . | | . | AHA | | . | AHA | . |< - - -| | . |<- - - - - - - -| -.- - - - - - - | | | . | Update config | . | | | . |--------------->| . | | | . | | . | | | . | | . | | | . | | . | | |AAA Rep: stat,RPI,KR | | . | | |<--------------------| | . | | | . | | . | | +.......................+ LC = Local AAA Challenge RPI = Replay Protection Indicator used between host and AAAH CR = AAA Credential ID = Client Identifier KR = Key Reply UCP = Uncontrolled part CP = Controlled part AHR = AAA Host Request (using an AAA protocol) AHA = AAA Host Answer (using an AAA protocol) The figure describes the authorization protocol exchanges in the generic case. A run of this protocol is initiated by either the attendant or the host. First, the attendant (uncontrolled part in the router) sends a local challenge to the host. The host then constructs Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 4] Internet Draft AAA for IPv6 5 January 2000 an AAA credential which securely binds the local challenge, the client identifier, any replay protection indicator used between the host and AAAH, and other necessary information. The credential is such that it can be verified by AAAH. The host then sends an ``AAA Request'' message containing the credential and the information necessary to verify it. The attendant checks that the local challenge included in the AAA Request is valid, extracts the AAA related information and sends them to AAAL using an appropriate AAA protocol. We label this message, AAA Host Request (AHR). AAAL forwards AHR to AAAH, which verifies the credential and sends back the result, and any necessary keys. We label this reply message AAA Host Answer (AHA). The AAAL forwards AHA to the attendant. AAAL may also forward any necessary keys. The attendant extracts the relevant data from AHA and forwards them to the host. The attendant updates configuration of the packet filter (controlled part in the router) so that traffic to and from the host is allowed to pass through. 3.2. Client Identifier The client identifier MUST enable AAAL to identify a suitable AAAH for carrying out all necessary authorization steps. A NAI [1] is often used to convey identities of users although IPv6 networks may well be constructed to determine the user's identity based only on the IPv6 address of the user's host. Therefore, the client identifier MAY be a NAI or an IPv6 address. The NAI MAY also identify the user to AAAL, although this is not necessary (e.g., the user part of the NAI may be a pseudonym intelligible only to AAAH). 3.3. Replay Protection Each participant in the protocol SHOULD verify the freshness of the protocol messages in order to protect itself from replay attacks. Replay protection between AAAL and AAAH, and between AAAL and attendant are handled by the AAA protocol. Therefore, we only need to consider replay protection between the host and the other entities. The attendant ensures freshness of an AAA Request message from the host by verifying that the local challenge included in the Request is a recent one. The host and AAAH may use either timestamps or random challenges (nonces) for replay protection. The former is straightforward. The latter is as follows. In the AAA Reply, AAAH sends an AAAH challenge. When the host makes the next AAA Request, it includes this AAAH challenge. It also includes its own host challenge. When AAAH receives this request, it verifies that the AAAH challenge is current. In the reply, AAAH copies the host challenge, and includes a new AAAH Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 5] Internet Draft AAA for IPv6 5 January 2000 challenge. This way, the host can verify the freshness of the reply from AAAH. If the AAAH challenge in an AAA Request is not valid, or if the client sends an explicit request for an AAAH challenge, AAAH will reply with a new AAAH challenge. 3.4. AAA Credential An AAA credential is created by the client and is verified by AAAH. The creation and verification is based on a security association shared between the client and AAAH. The credential SHOULD securely bind the following pieces of information: - Client identifier, - Local AAA challenge, if one was provided by the attendant, and - Depending on the style of replay protection being used between the host and AAAH, either a timestamp or a pair of challenges. In specific instantiations, additional data may be included in the computation of the AAA Credential. The exact algorithm used to compute the AAA Credential depends on the security association between the client and AAAH. HMAC_MD5 is a suitable algorithm, based on a shared secret between the client and AAAH. 4. Instantiation with Stateless Address Autoconfiguration In this section, we describe how the general protocol sketched in Section 3 can be used with Stateless address autoconfiguration [7]. 4.1. Structure of Protocol Messages We define a five new ICMPv6 messages to transport AAA data between the host and the attendant. In addition, we defined several options that can be embedded in a AAA Protocol Message. Detailed definitions of these messages are given in Section 7. Here we give a brief description of each AAA protocol message type, and each AAA option. In addition, we also defined an AAA Challenge option to Router Advertisement using which the attendant can send a challenge to the host. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 6] Internet Draft AAA for IPv6 5 January 2000 4.1.1. AAA Protocol Message types From host to attendant: AAA Request: Request for client authorization. AAA Home Challenge Request: Request for a new challenge from AAAH. AAA Teardown Request: Request to terminate the currently active AAA registration. From attendant to host: AAA Reply: Reply to AAA Request. AAA Teardown: Indication of termination of the currently active AAA registration. This may be in response to a AAA Teardown Request. 4.1.2. AAA Protocol Message options Each AAA Protocol Message specifies what AAA options may accompany it. Currently, the following options are defined. Security Data: This option is intended to carry security data. Currently, two subtypes are defined. AAA Credential: Sent by the client; used by AAAH to verify the authorization of the client. AAAH Authenticator: Sent by AAAH; used by the client to verify the authenticity of AAA Reply. Client Identifier: This option should enable AAAL to determine the AAAH to which an AAA Request is to be forwarded. Currently, two subtypes are defined: NAI, and IPv6 address. Generalized Key Reply: This option is used to distribute session keys to be used by the host. Currently several pairs of subtypes are defined. Challenge: This option is used to carry nonces used for replay protection. Currently three subtypes are defined: Local Challenge: Challenge issued by the attendant to the host. Home Challenge: Challenge issued by AAAH to the host. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 7] Internet Draft AAA for IPv6 5 January 2000 Host Challenge: Challenge issued by the host to AAAH. Timestamp: This option is used to carry timestamp information used for replay protection. IPv6 Address: This option is used to carry IP address information. Lifetime: This option indicates the lifetime of an AAA verification. 4.2. Protocol Overview 4.2.1. Basic operation The basic operation follows the model described in Section 3.1. When an IPv6 host starts up or enter a new subnet, it receives a Router Advertisement with a AAA Challenge option. As is usual, this Router Advertisement is either broadcast periodically, or is sent in response to a Router Solicitation by the host. The host will construct a tentative IP address and reply with an AAA Request ICMPv6 message with the following options: - Local Challenge option into which the challenge in the Router Advertisement is copied. - Either Timestamp option or both AAAH Challenge and Host Challenge options - IPv6 Address option consisting of the tentative IPv6 address chosen - Client Identifier option consisting of the client's NAI or some long term IPv6 address - AAA Credential option constructed by concatenating all of the preceding options and applying the algorithm specified by the security association between the host and AAAH. When challenges are used for reply protection, the host MUST include the current AAAH challenge (received from AAAH via a previous AAA Reply message) in the AAAH Challenge option, and a random number in the Host Challenge option. If the host does not have an AAAH challenge, it SHOULD send an AAA Home Challenge Request message first (see Section 4.2.2. The host MAY perform Duplicate Address Detection (DAD) before sending the AAA Request. In that case, the source address of AAA Request Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 8] Internet Draft AAA for IPv6 5 January 2000 MUST be the chosen IPv6 address. Otherwise, if the host has not yet performed DAD, the source address of AAA Request MUST be the unspecified address. On receiving the Request, the attendant MUST check if the chosen address is already in use. If it is, the attendant MUST send an AAA Reply with code ADDRESS_IN_USE. Otherwise, the attendant will extract AAA data and forward them to AAAL in an AHR message using an AAA protocol, which is then forwarded to AAAH. The data in each AAA option MUST be conveyed to AAAH by the AHR message. In return, AAAH will construct an AHA message containing information in a suitable form that can be be extracted by the attendant and conveyed to the host in an AAA Reply message with appropriate options. The following options are relevant: - Either Timestamp option or both AAAH Challenge and Host Challenge options - One or more Key Reply options - Lifetime option - AAAH Authenticator option We describe AAAH behavior in terms of what the host should eventually receive in the AAA Reply. If the AAA Credential is incorrect, the host MUST receive an AAA Reply with code INVALID_CREDENTIAL. If challenges are used for replay protection, and if the AAAH challenge is absent or invalid, the AAA Reply SHOULD have a code NEW_CHALLENGE, and SHOULD contain an AAAH Challenge option. If timestamps are used for replay protection, and the Timestamp option is absent or invalid, the AAA Reply SHOULD have code INVALID_TIMESTAMP. AAAH SHOULD choose a validity period for the verification which should be included in the Lifetime option of AAA Reply. If AAAL proposes its own lifetime value (in the AHR message), then the Lifetime option MUST contain the lower of the two values. If AAAH chooses a key to be used between the attendant and the host, that key SHOULD be encoded in a Host-Attendant Key Reply option. If timestamps are used for replay protection, there MUST be a timestamp option. If challenges are used for replay protection, AAAH MUST copy the Host Challenge, and include a new random number in the AAAH Challenge. Finally, AAAH should compute an authenticator, to be included in an AAAH Authenticator option, by concatenating all the preceding options intended for the host, and applying the algorithm specified by the security association between the host and AAAH. In addition, AAAH MAY include information in the AHA message intended for AAAL. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 9] Internet Draft AAA for IPv6 5 January 2000 If the verification is successful, AAAH will send back an AHA message indicating success to AAAL. AAAL will forward this to the attendant. If there are any keys distributed by AAAH, AAAL MUST re-encode those keys for the attendant. The attendant MUST add an entry for a host in its neighbor cache and at the same time update the packet filter with the client's host IP address when the AAA verification for the client has been successful. The lifetime of these entries MUST be set to the value specified in the AHA message. The attendant will extract all information in the AHA message intended for the host and send them back in an AAA Reply ICMPv6 message. If the source address of the AAA Request was the unspecified address, the corresponding AAA Reply MUST be sent to the all-nodes multicast address. Otherwise the AAA Reply MUST be sent to the source address of the corresponding AAA Request. The attendant MUST create security associations for the host corresponding to any keys distributed to it by AAAL. When the host receives an AAA Reply indicating success, it MUST verify the AAAH authenticator and the validity of the replay protection indicator. If verification succeeds, the host MUST create security associations for the attendant. The host MUST associate the lifetime specified in the Lifetime option with the address that was authorized. When the lifetime expires, the host SHOULD re-initiate the AAA process. 4.2.2. Challenge Request If the host does not have a valid AAAH challenge, it SHOULD send an AAA Home Challenge Request message. This SHOULD include the Host Challenge option and MAY include the Client Identifier option. The AAA Reply SHOULD have code NEW_CHALLENGE, and SHOULD include an AAAH Authenticator option. 4.2.3. Termination It is also possible to terminate valid sessions. To terminate a session, the attendant clears the packet filter and sends a AAA Teardown 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. The host may request termination by sending an AAA Teardown Request message. The attendant MUST reply to this message with an AAA Teardown message. Both of these messages SHOULD be protected by an IPSec AH header. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 10] Internet Draft AAA for IPv6 5 January 2000 4.3. Initiation of the AAA Process The AAA process can be initiated either from the host or from the attendant. The attendant can initiate the process by sending a Router Advertisement with the AAA Challenge option. The host can initiate the process by sending a Router Solicitation. 5. Instantiation with Mobile IPv6 There are two ways to handle Mobile IPv6. First, the host could do the AAA processing when it obtains a care-of address, and then it could send a binding update to the home agent, and possibly to the previous router and other correspondents. If the home agent and AAAH belong to the same domain, it may be more efficient to bundle the binding update to the home agent in the AAA Request message so that the delay is minimized. We support this possibility by defining a new option called Embedded Data option. The host generates an IPv6 packet containing the binding update to the home agent, but instead of sending it directly, it includes it in the AAA Request as the payload of an Embedded Data option. AAAH will extract the binding update IPv6 packet and send it to the home agent. The home agent SHOULD send the binding acknowledgement back to AAAH so that it can be similarly transported to the host as part of the AAA Reply. In addition, we define new subtypes to the AAA Generalized Key Reply option so that AAAH could distribute authentication keys for use between the home agent and the mobile node. 6. Instantiation with DHCPv6 WARNING: This section has not yet been converted to conform to the general model described in Section 3. 6.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 Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 11] Internet Draft AAA for IPv6 5 January 2000 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 AAAL. AAAL uses the AAA network to forward the AAA message to AAAH. AAAH processes the AAA message and forms a reply to AAAL. The reply may contain keys, policy information, etc. targeted to AAAL, the DHCP server and/or the DHCP client. 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 AAAL and the DHCP server and forwarded to the DHCP client. Based on the reply from AAAL, the DHCP server forms a DHCP Reply message either accepting or denying the registration attempt. The opaque AAA data received from 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. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 12] Internet Draft AAA for IPv6 5 January 2000 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 6.2. Renewal of the AAA credentials 6.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. 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. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 13] Internet Draft AAA for IPv6 5 January 2000 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. 6.4. DHCP Relay Considerations A DHCP relay receiving any AAA extensions MUST forward these extensions unaltered between the client and the server. 6.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 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 Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 14] Internet Draft AAA for IPv6 5 January 2000 sending the information contained in the AAA extensions to AAAL, the DHCP server checks the correctness of the DHCP Request message. If 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 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. 7. Message Formats for Stateless Address Autoconfiguration 7.1. AAA Challenge Option The AAA challenge option is applicable to 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 | 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. 7.2. AAA Protocol Messages AAA Messages are new ICMPv6 messages. They have the following general structure. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 15] Internet Draft AAA for IPv6 5 January 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message body | + + Type The following new types are defined: AAA Request: TBD AAA Home Challenge Request: TBD AAA Teardown Request: TBD AAA Reply: TBD AAA Teardown: TBD Code The code field depends on the message type. Currently the following Code fields are defined. - For AAA Reply SUCCESS: 0 NEW_CHALLENGE: 1 ADDRESS_IN_USE: 20 INVALID_CREDENTIAL: 50 INVALID_TIMESTAMP: 51 - For AAA Teardown SUCCESS: 0 - No Code values are defined for the remaining AAA message types. The Code field MUST be set to zero. Message body The message body may consist of one or more options. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 16] Internet Draft AAA for IPv6 5 January 2000 7.3. AAA Protocol Message Options The general structure of an AAA Protocol Message Option is as follows. 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 | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option data | + + Type The Type field identifies the option. Currently, the following types are supported. The most significant bit of the Type indicates if the option is unskippable (0) or skippable (1). Subtype Each option type may be further subdivided. The Subtype field identifies option at the next level of granularity. Length The Length field indicates the size of the Option data in octets. Option data The format of option data is depends on the type and subtype, and is defined below. 7.3.1. Client Identifier option The Client Identifier option is used by AAAL to decide where to route the AAA request, and by AAAH in verifying the AAA Credential. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 17] Internet Draft AAA for IPv6 5 January 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 | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | + + Type 1 (unskippable) Subtype Currently two subtypes are defined: NAI (0) and IPv6 address (1) Length For subtype 1, the Length should be 16. Identifier For subtype 0, this field contains a NAI formatted according to RFC2486 [1]. For subtype 1, this field contains an IPv6 address. 7.3.2. Security Data 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 | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Data | + + Type 2 (unskippable) Subtype Currently two subtypes are defined: AAA Credential (0) and AAAH Authenticator (1) Length Length of the option in octets, not including the first four octets. SPI The security parameter index to be used in interpreting the Security Data. Security Data The actual payload. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 18] Internet Draft AAA for IPv6 5 January 2000 7.3.3. Challenge The Challenge option is used to convey nonces for replay protection between various pairs of entities. 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 | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge | + + Type 3 (unskippable) Subtype Currently three subtypes are defined: - Local Challenge: Challenge issued by the attendant to the host (0) - Home Challenge: Challenge issued by AAAH to the host (1) - Host Challenge: Challenge issued by the host to AAAH (2) Length Length of the challenge in octets. Challenge The actual challenge data. 7.3.4. Generalized Key Reply This option is used to convey keys distributed by AAAH for use between the host and other entities. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 19] Internet Draft AAA for IPv6 5 January 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 | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AAAH SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer IPv6 Address | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Key Data | + + Type 4 (unskippable) Subtype Currently three pairs of subtypes are defined: - Host-Attendant authentication key: Key to be used between the current attendant and the host for IPSec authentication (0) - Host-Attendant encryption key: Key to be used between the current attendant and the host for IPsec encryption (1) - MN-HA authentication key: Key to be used between the home agent and the host for IPsec authentication (3) If the most significant bit of the Subtype value is 1, the ``Peer IPv6 Address'' field is present. Otherwise, it is absent. Length Length of the option in octets except the first four octets. AAAH SPI This field indicates the security association between the host and AAAH which should be used by the host to interpret the Encoded Key Data field. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 20] Internet Draft AAA for IPv6 5 January 2000 Key SPI This field indicates the SPI value for the new security association into which the key should be inserted. Peer IPv6 Address When present, this field indicates the IPv6 address of the peer. This is useful when the client does not already know the address to be used. This field is present in subtypes 128 and above. Encoded Key Data This field contains the key, along with any other information required by the host to create the security association. The contents of the field MUST be encrypted by AAAH as specified by AAAH SPI. 7.3.5. Timestamp Timestamp field may be used for replay protection between the host and AAAH. 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 | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | + + Type 5 (unskippable) Subtype Currently no subtypes are defined. Should be zero. Length Length of the Timestamp in octets. Timestamp Timestamp value in some format mutually intelligible to the host and AAAH 7.3.6. IPv6 Address This option is used by the host to convey the IPv6 address it has chosen. There may be other uses for this option, too. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 21] Internet Draft AAA for IPv6 5 January 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 | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 6 (unskippable) Subtype Currently no subtypes are defined. Should be zero. Length 32 IPv6 Address A valid IPv6 address. 7.3.7. Lifetime This option is used to indicate the validity period of a successful AAA verification. 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 | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 7 (unskippable) Subtype Currently no subtypes are defined. Should be zero. Length 4 Lifetime Lifetime in seconds. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 22] Internet Draft AAA for IPv6 5 January 2000 7.3.8. Embedded Data This option is used to transport specific kinds of embedded data in the AAA messages. 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 |WH |Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Embedded Data | + + Type 8 (unskippable) WH This field indicates who should process the embedded data. It is interpreted as follows (values in binary) - 00 - Recipient of the AAA Protocol message (i.e., either the host or the attendant) - 01 - AAAL - 10 - AAAH - 11 - reserved Subtype Currently two subtypes are defined: - MN-HA binding update (0) - HA-MN binding acknowledgement (1) Data The actual embedded data itself. For subtype 0, this SHOULD be an IPv6 packet addressed to the HA, and containing a binding update. For subtpe 1, this SHOULD be an IPv6 packet addressed to the CoA, and containing a binding acknowledgement from the HA. For example, to bundle the HA binding update with AAA processing, the host will first generate a binding update, and insert it into an embedded data option of the AAA Request message, with WH = 10 (binary) and Subtype = 0. Based on the value of WH, the attendant will extract the Embedded Data and forward it to AAAH via AAAL. Based on the Subtype, AAAH will forward the binding update to the home agent, and will receive a binding acknowledgement in reply. The attendant will forward the Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 23] Internet Draft AAA for IPv6 5 January 2000 binding acknowledgement in an Embedded Data option to the AAA Reply message, with WH - 00 (binary) and Subtype = 1. 8. Message Formats for Stateful Address Autoconfiguration with DHCPv6 WARNING: This section has not yet been converted to conform to the general model described in Section 3. 8.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]. 8.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 in order to deliver some AAA credentials to the DHCP client. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 24] Internet Draft AAA for IPv6 5 January 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. 8.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 value TBD. 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 5 July 2001 [Page 25] Internet Draft AAA for IPv6 5 January 2000 8.4. Generalized AAA Key Reply Extension [to be described] Should we defined a generalized AAA Key Reply extension in the style of [6] that can carry encoded keys back to the host and the host can (somehow) insert them into the IPSec SA database? 9. Security Considerations Source address based packet filtering does not guarantee that only authorized clients will be able to send out traffic through the router. An attacker can fake the source address of IP packets. In situations where strong protection is needed, hosts should be required to use an IPSec AH tunnel to the router. 10. Open Issues and Discussion 10.1. 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. 10.2. Use of Destination Options An alternative to defining new ICMPv6 messages and associated options will be to define new IPv6 destination options for all AAA related payload. One disadvantage is that the length of destination options is limited by the 8-bit length field. An advantage is that embedded data may be transported more naturally using either a Routing Header or IP-in-IP encapsulation, thereby avoiding the need for something like the Embedded Data option. Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 26] Internet Draft AAA for IPv6 5 January 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, January 2000. Work in progress. [5] E. Nordmark. IPv6 hooks for AAA and "host routing". Internet Draft, Internet Engineering Task Force, March 2000. [6] C. Perkins and P. Calhoun. Generalized Key Distribution Extensions for Mobile IP. Internet Draft, Internet Engineering Task Force, February 2000. [7] 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 5 July 2001 [Page 27] Internet Draft AAA for IPv6 5 January 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 5 July 2001 [Page 28]