UNAP Working Group Alper E. Yegin Internet Draft Xiaoning He Category: Standards Track Carl Williams Expires: May, 2002 DoCoMo USA Labs Yiqun Lisa Yin Satomi Okazaki NTT Multimedia Communications Labs November 2001 Secure Network Access Using Router Discovery and AAA draft-yegin-unap-snard-00 Status of this Memo 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 Internet access through public networks require authentication of clients and networks to each other. While there are currently used link-layer protocols such as PPP, it is very desirable to provide a network-layer solution that can work across multiple types of links. Authentication of roaming clients is generally handled by AAA protocols. In order to use AAA between the network and the client, we need a protocol to carry required messages. This draft defines how we can extend the standard router discovery protocol to use it as a carrier for the authentication purposes. Yegin, He, Williams, Yin, Okazaki Expires May 2002 Page 1 Internet Draft SNARD 14 November 2001 1. Introduction Public access IP networks are becoming widely deployed thanks to the developments in the wireless network access technologies such as 802.11. The most important challenge such networks are facing is in the area of client and network authentication. Each client has to be authenticated before any network access is granted to them. An unauthenticated client is a potential free-loader and a candidate malicious node whose identity we cannot track. Similarly, clients would want to authenticate the network so that they don't get tricked into operating in a malicious environment. Clearly a two-way authentication mechanism is essential to provide and receive public network access service in an IP environment. Currently there are numerous authentication mechanisms implemented and deployed for various access technologies. Examples include authentication of PPP and 802.11 networks. One drawback of such approaches is that these are link-layer solutions, as such their applicability is limited to specific access technologies. Providing a network-layer solution has the benefit of applying to all the possible link-layers beneath. This is what motivates developing an IP-layer solution for client-network authentication. Authenticating a roaming client to a network is clearly in the domain of AAA protocols (e.g., Radius, DIAMETER). While the protocol we are looking for doesn't define a new AAA mechanism, it clearly needs to use the existing AAA protocols. It doesn't define a new authentication protocol either. All it does is to provide a "carrier" for the existing AAA protocols to help authenticating clients and networks to each other. Similar carriers have been defined for Mobile IPv4 protocols in the form of extensions [MNAAA] to the base protocol [MIP4]. What we are looking for is a protocol that can be used as a "carrier" for the base IP protocol. Such a protocol can be used for IPv4, IPv6, Mobile IPv4, and Mobile IPv6. The carrier we have chosen for providing network authentication is router discovery mechanism [DISC4, DISC6]. This standard protocol can be extended to provide basic authentication functionality for both clients and networks. This seemed like a natural choice because the most essential service a network provides to a client is forwarding of IP packets (reachability). This service should not be provided or received without each party being authenticated. Discovery of this essentialservice is provided through router solicitation and router advertisement messages. Without authentication any client's solicitation would be answered by routers on the same link, and similarly clients would believe advertisements coming from any router on the same link. By securing this protocol exchange, we can ensure that only legitimate clients get forwarding service, therefore connected to the network, and clients only believe in legitimate routers' advertisements. Yegin, He, Williams, Yin, Okazaki Expires May 2002 Page 2 Internet Draft SNARD 14 November 2001 In addition to this semantic fitness, another benefit of using router discovery messages is the message re-use. Router discovery is a process a client has to go through anyways. We can avoid additional protocol signaling by piggybacking client-network authentication on top of this mandatory exchange. This optimization is essential for gaining network access in the fastest way possible. And finally, multicast nature of router discovery gives clients a chance to probe all possible routers at once. Therefore clients can eliminate illegitimate routers (possible "fake bank tellers") in a single round trip. Denial-of-service attacks by malicious routers can be prevented easily. This draft outlines a new method to authenticate clients and networks to each other using extended router discovery messages as carriers. This early version of the draft does not include any protocol format details, but rather lays out the framework. Related work can be found in [AAA6] and [AAAHOOKS]. 2. Terminology 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 RFC 2119 [KEYWORDS]. Additionally, the following terminology is used in this draft: Client: A roaming device which can gain access to network after successful authentication. Access Router: A router that provides inbound and outbound packet forwarding service to the client. There can be one or more access routers in a visited domain. AAAH: AAA server in the home domain of the client. This is the server which is capable of authenticating the client without consulting any other AAA server. AAAV: AAA server in the visited domain. Typically single AAAV is consulted by many access routers in the domain. AAAV has to consult with AAAH for the initial authentication of a client. Domain: A collection of AAA servers and access routers. Yegin, He, Williams, Yin, Okazaki Expires May 2002 Page 3 Internet Draft SNARD 14 November 2001 Authentication token: A cryptographic value (e.g., keys or digital certificates) that belongs to an entity. It can be used to verify the validity of a message originated from the entity. Authentication extension: An extension that is computed by the sender of a message based on the security association between the sender and the intended recipient. The recipient later uses the authentication extension and an authentication token for the sender to verify the validity of the message. +---------------------------+ +----------------+ | +------+ | | +------+ | | | AAAV |-----------..Internet..------| AAAH | | | +------+ | | +------+ | | / \ | | | | / \ | | | | / \ | | Home Domain | | +-----+ +-----+ | +----------------+ | | AR1 | | AR2 | | | +-----+ +-----+ | | | | | | | | | | | +--------+ | | | Client | | | +--------+ | | | | | | Visited Domain | +---------------------------+ 3. Protocol Overview 3.1. Security Associations One of the requirements we are trying to satisfy with this protocol is to provide a fast authentication mechanism. A protocol is faster if it involves shorter round-trips for protocol signaling. Anytime a signal has to travel to AAAV or especially to AAAH servers, there is certain latency involved. In some cases it is inevitable to communicate with these remote servers. But we must limit this communication as much as possible. One way to achieve this is to establish security associations with the local entities, so that the client and the network can authenticate each other without consulting remote servers. Yegin, He, Williams, Yin, Okazaki Expires May 2002 Page 4 Internet Draft SNARD 14 November 2001 These are the initial security associations we can assume to have from the beginning: - Between client and AAAH: AAAH is the only entity that can authenticate the client initially. - Between AAAV and AAAH: This can be direct or indirect through some broker AAA servers. - Between AAAV and access routers in the visited domain: Trust within a domain. By using these "seed" security associations, this protocol establishes two new security associations: - Between access router and client: By establishing this security association during the initial network access, subsequent network access requests to the same access router can be authenticated without consulting any AAA servers. - Between AAAV and client: By establishing this security association during the initial network access, subsequent network access requests to a new access router in the same domain can be authenticated without consulting AAAH. Protocol signaling defined in this draft not only helps clients and access routers authenticate each other, but also establishes local security associations by distributing keying information. 3.2. Initial Router Discovery (client entering a new domain) Protocol signaling for network access authentication using router discovery protocol can be illustrated as follows: Client AR AAAV AAAH | RS+ | | | +-----------> | AAA Req | | | +----------> | AAA Req | | | +----------> | | | | | | | | AAA Rep | | | AAA Rep | <----------+ | RA+ | <----------+ | | <-----------+ | | | | | | Client begins the router discovery by sending a router solicitation message. This is a multicast message which is received by all routers on the same link as the client. Unlike a regular router solicitation message, this one includes the proof of client's identity. This proof is carried in the form of extensions to the standard router solicitation packet (therefore the acronym "RS+"). Yegin, He, Williams, Yin, Okazaki Expires May 2002 Page 5 Internet Draft SNARD 14 November 2001 RS+ is the collection of the following components: - Standard router solicitation message as defined in [DISC4, DISC6] - A new extension that carries client's identifier. This can be an NAI [MIPNAI] - Another new extension that authenticates the router solicitation message. This is an authentication extension computed by the client using the security association between the client and its AAAH. This extension proves client’s true identity which can only be verified by AAAH initially. Access router SHOULD consult with AAAV upon receiving the RS+ message. Access router cannot authenticate the client until it receives a positive response from AAAV. It SHOULD NOT send back a router advertisement until this reply is received. Authentication of this initial RS+ can only be verified by the AAAH. Access router delegates this verification to AAAV. AAAV can figure out which AAAH to consult with by looking at the client identifier in the RS+. The interaction between the access router and AAAV, and between AAAV and AAAH is outside the scope of this draft. These AAA request and AAA reply messages must be defined by a AAA protocol, such as Radius or DIAMETER. Encryption and authentication of these messages is outside the scope of this draft. These are the requirements from the AAA request and AAA reply messages: . AAA request messages SHOULD carry parts or full of RS+ so that AAAH can authenticate the client. . AAA reply from AAAH to AAAV SHOULD send back the result of this verification, together with two authentication tokens, one for AAAV and the other for the client. These tokens will be used to authenticate AAAV and the client by each other in subsequent exchanges. . AAA reply from AAAV to access router SHOULD pass along the necessary information from incoming reply (above) and also two authentication tokens, one for the access router and the other for the client. The access router and the client will use these tokens to authenticate each other in subsequent exchanges. Access router can determine the authenticity of the client upon receiving a reply from AAAV. Access router SHOULD send a unicast router advertisement if this is an authentic client. This router advertisement, RA+, has the following components: - Standard router advertisement message as defined in [DISC4, DISC6] - A new extension that carries the authentication token for the access router. - Another new extension that carries the authentication token for AAAV. Yegin, He, Williams, Yin, Okazaki Expires May 2002 Page 6 Internet Draft SNARD 14 November 2001 - Another new extension which is the authentication extension computed using the (above) established security association between the access router and the client. Client SHOULD verify the authenticity of the received router advertisement by verifying the authentication extension using the authentication tokens included in the message. It SHOULD also learn the AAAV and access router authentication tokens from this advertisement packet. This initial router discovery messaging not only authenticates the client and the access router to each other, but it also accomplishes key distribution. Client possesses tokens to verify subsequent messaging with access router and AAAV. Similarly, access router and AAAV can authenticate the client without further consulting with AAAH. 3.3. Subsequent Router Discovery (same access router) Following diagram shows the protocol signaling after initial router discovery as outlined in section 3.2. This is the case where the client is assumed to be still attached to the same access router in the same domain. Client AR AAAV AAAH | RS+ | | | +-----------> | | | | RA+ | | | | <-----------+ | | | | | | Subsequent solicitation messages on the same link would also use the same format RS+ format as defined in section 3.2. If the client has already gone through an authenticated router discovery earlier, access router on this link SHOULD recognize this client and readily authenticate it using the authentication token distributed earlier. Therefore authentication of this client involves neither AAAV nor AAAH. Access router SHOULD send the RA+ that includes: - Standard router advertisement message as defined in [DISC4, DISC6] - A new extension which is the authentication extension computed using the established security association between the access router and the client. Similarly the client SHOULD authenticate the received RA+ by using pre-distributed access router authentication token. Yegin, He, Williams, Yin, Okazaki Expires May 2002 Page 7 Internet Draft SNARD 14 November 2001 3.4. Subsequent Router Discovery (new access router, same domain) If the client moves within the domain, it can attach to another access router which is not aware of the client's identity. In this case authenticated router discovery involves following messages: Client AR AAAV AAAH | RS+ | | | +-----------> | AAA Req | | | +----------> | | | | | | | | AAA Rep | | | RA+ | <----------+ | | <-----------+ | | | | | | Client SHOULD send the same RS+ message as defined in 3.2. If this is the first time access router is receiving a RS+ from the client, it wouldn't have the token to verify the client's authenticity. Therefore it SHOULD consult with AAAV. If this is a domain that the client has been visiting, then AAAV SHOULD recognize this client and be able to authenticate it without further contacting AAAH. This is made possible by the authentication tokens distributed through an earlier discovery. AAA Reply and RA+ transmitted will use the same format as defined in 3.2. This RA+ authenticates both access router and AAAV to the client, and also distributes an authentication token for this new access router. Therefore subsequent router discovery exchanges between this client and access router SHOULD NOT require any AAAV involvement. 3.5. Unsolicited Router Advertisements If an access router chooses to send periodic (unsolicited) router advertisements, it SHOULD compose RA+ as follows: - Standard router advertisement message as defined in [DISC4, DISC6] - A new extension that carries the authentication token for the access router. - Another new extension that carries the authentication token for AAAV. - Another new extension which is the authentication extension computed using the established security association between the access router and the clients. (Note: Details of such a security association depends on whether we are using symmetric or asymmetric keying, which is left to a later version of this draft) Roughly, a client which has already established a security association with this access router through an initial router discovery exchange SHOULD be able to authenticate the above Yegin, He, Williams, Yin, Okazaki Expires May 2002 Page 8 Internet Draft SNARD 14 November 2001 unsolicited router advertisement message. If this client is new to this link but has been roaming in this domain, then it SHOULD authenticate this message by leveraging on its security association with the AAAV. If the client is new to this domain, then it SHOULD go through the full router discovery as described in section 3.2. 3.6. Re-authentication At any time each side of the communication should be able to kick start this protocol to verify authentication. This is important where malicious entities can replace legitimate ones during an already authenticated communication. Client can start this process by sending a RS+ at any time. Access router should be able to respond with a RA+ that passes the authentication check. Access router SHOULD induce this process by sending a unicast router advertisement with very low router lifetime. This indicates that the access router is about to stop serving this client. Client's natural response to such an indication SHOULD be to send a RS+ to discover other available routers on the same link. This starts the authentication process in which the original access router has a chance to respond with a RA+. Re-authentication can be accomplished within the same framework by using router discovery messages as outlined in this section. 3.7. Interoperation with "Old" Protocol We need to analyze this new protocol's interaction with the standard protocol [DISC4, DISC6] to make sure they do not interfere with each other. When both the client and the access router support the current standard protocol, they can function without any problems. Similarly, when they both support the new extended protocol, the operation leaves no ambiguity as outlined in this draft. We need to consider two other cases: New client, old access router: Client would send a RS+ which includes the new extensions that are not recognized by the access router. Access router SHOULD ignore these extensions and process this as a simple "RS" and send back a simple "RA". Now it is up to the client to decide whether to use this "unauthenticated" advertisement or not. Yegin, He, Williams, Yin, Okazaki Expires May 2002 Page 9 Internet Draft SNARD 14 November 2001 Old client, new access router: Client would send a simple "RS" which does not include any of the new extensions. Upon receiving such an "unauthenticated" solicitation, it is up to the router whether to send back a "RA" or not respond at all. In either case, the "new" entity can detect whether the other supports the new extensions or not, and respond accordingly. Whether to respond/accept unauthenticated messages is a policy decision. 3.8. Symmetric-asymmetric Keying Router discovery messages are used as carriers for key distribution. While this draft does not go into details of how this is done, both symmetric and asymmetric cryptography can be applied by using this method. Details of specific cryptographic approaches and protocol formats are left to a later version of this draft. 4. Advantages of This Approach This is a network access authentication protocol that uses router discovery messages as a carrier for AAA exchanges. Using router solicitation and router advertisement messages as outlined in this draft has certain advantages in securing network access. This method is a natural extension to an already established standard [DISC4, DISC6]. It does not define new protocol types, but just extensions to existing protocol signaling. Seeing router solicitation as a "request for service" and router advertisement as a "service advertisement" makes this a semantically fit choice. Router discovery is the first step a client should take to have off-link connectivity. Piggybacking the authentication of the client and the router to this message exchange saves extra protocol signaling. This savings are critical for mobile and wireless networks. Since router discovery is common to both IPv4 and IPv6 networks, this method is applicable to both protocols. Mobile IPv4 [MIP4] and Mobile IPv6 [MIP6] also rely on router discovery, therefore they can take advantage of this authentication method as well. Mutual authentication of the client and the router is possible by using this method. Authentication of the router is critical for eliminating "fake bank teller" problem. Client can eliminate malicious or unauthenticated access routers in single round trip by sending a multicast RS+. Client would receive possibly multiple RA+ to its single RS+. It can examine each one of them and eliminate unauthenticated routers and pick one of the "good" routers. Client Yegin, He, Williams, Yin, Okazaki Expires May 2002 Page 10 Internet Draft SNARD 14 November 2001 can immediately identify legitimate routers among malicious routers using this parallel process. While authentication of entities is a critical requirement for network access, carrying out this operation as fast as possible is another requirement for uninterrupted communication. This method optimizes the authentication process by minimizing communication with remote entities, such as AAAH and AAAV. AAAH is consulted only once during the initial router discovery after a client enters a new domain. AAAH is never consulted as long as the client stays within this domain. AAAV is consulted only when the client moves from one access router to another one in the same domain. Neither AAAV nor AAAH is consulted as long as the client stays connected to the same access router. Minimizing the protocol signaling to close-by entities shortens the delays associated with the authentication process, therefore minimizes its effect on ongoing communication. 5. Future Work Current version of the draft outlines the framework of using router discovery for securing network access. Subsequent versions of this draft will specify the protocol details (e.g., packet formats). Router discovery is the very first protocol exchange a client would go through in order to establish off-link reachability. Using this messaging as a tool to distribute keys and establish security association between the client and the access router makes it possible to secure rest of the communication between two. Using this security association can help secure subsequent address resolution (ARP/RARP) and neighbor discovery protocol signaling. Therefore it can be used to solve the fundamental link security problem. Application of this protocol to secure further communication on the link is left to a later version of this draft. 6. Security Considerations This draft outlines a protocol to provide secure network access by using router discovery mechanism as a carrier. Authenticated router solicitations are replied by a router advertisement that not only announces availability of routing services to authentic clients, but also distributes keys for further secure communication between the client and the access router. This keying information can be used to authenticate and encrypt regular data traffic (other than the router discovery) between the client and the access router. Layer 3 security using IPsec or a lower layer security mechanism can be used for this purpose. This requires a way to pass distributed keys to relevant protocols, which is outside the scope of this draft. Yegin, He, Williams, Yin, Okazaki Expires May 2002 Page 11 Internet Draft SNARD 14 November 2001 IPR Statement The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Acknowledgements We would like to thank Atsushi Takeshita, Aki Yokote, and James Kempf of DoCoMo USA Labs for their valuable comments and contributions. References [KEYWORDS] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels", Request for Comments (Best Current Practice) 2119, March 1997. [DISC4] S. Deering. "ICMP Router Discovery Messages", Request for Comments 1256, September 1991 [DISC6] T. Narten, E. Nordmark, W. Simpson. "Neighbor Discovery for IP Version 6", Request for Comments 2461, December 1998. [MIP4] C. Perkins. "IP Mobility Support", Request for Comments 2002, October 1996. [MIP6] D. Johnson and C. Perkins. "Mobility support in IPv6", draft-ietf-mobileip-ipv6-14.txt, July 2000. [AAA6] P. Flykt, C. Perkins, T. Eklund. "AAA for IPv6 Network Access", draft-perkins-aaav6-04.txt, July 2001. [AAAHOOKS] E. Nordmark. "IPv6 Hooks for AAA Registration and Host Routing", draft-nordmark-ipv6-aaa-hooks-00.txt, March 2000 (expired). [MIPNAI] P. Calhoun, C. Perkins. "Mobile IP Network Access Identifier Extension for IPv4", Request for Comments 2794, March 2000. [MNAAA] C. Perkins, P. Calhoun. "Mobile IPv4 Challenge/Response Extensions", Request for Comments 3012, November 2000. Yegin, He, Williams, Yin, Okazaki Expires May 2002 Page 12 Internet Draft SNARD 14 November 2001 Authors' Addresses Alper E. Yegin DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA, 95110 USA Phone: +1 408 451 4743 Email: alper@docomolabs-usa.com Xiaoning He DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA, 95110 USA Phone: +1 408 451 4737 Email: xiaoning@docomolabs-usa.com Carl Williams DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA, 95110 USA Phone: +1 408 451 4741 Email: carlw@docomolabs-usa.com Yiqun Lisa Yin NTT Multimedia Communications Labs 250 Cambridge Avenue, Suite 300 Palo Alto, CA 94306 USA Phone: +1 650 833 3612 Email: yiqun@nttmcl.com Satomi Okazaki NTT Multimedia Communications Labs 250 Cambridge Avenue, Suite 300 Palo Alto, CA 94306 USA Phone: +1 650 833 3631 Email: satomi@nttmcl.com Yegin, He, Williams, Yin, Okazaki Expires May 2002 Page 13 Internet Draft SNARD 14 November 2001 Full Copyright Statement "Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Yegin, He, Williams, Yin, Okazaki Expires May 2002 Page 14