Mobile IP Working Group S.Mizuno INTERNET DRAFT J.koga Expires: April 2003 H.Ohwada K.Suzuki Y.Takagi NTT Corporation October 2003 PKI Support in Hierarchical Mobile IPv6 Status of This Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mipshop@ietf.org 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 Hierarchical Mobile IPv6 (HMIPv6) is one of the key technologies for global IP mobility service network. A Home Agent (HA) and a Mobility Anchor Point (MAP) can manage the movement of Mobile Nodes (MNs) dispersedly. The HA provides MNs with global mobility and the MAP provides them with local mobility. To provide HMIPv6 services globally, it is essential to realize secure communication between the MNs and the MAPs without having their individual information in advance, because the MAPs often belong to the different networks from the MNs they manage. mizuno, et al. [Page 1] Internet Draft HMIPv6-PKI October 2003 This draft introduces a network architecture for deploying scalable and secure HMIPv6 services. In this architecture, user authentication and service authorization for the MNs are achieved by extending the latest Public Key Infrastructure (PKI) technology which is combined with Internet Key Exchange (IKE) technology. A MN and A MAP have only their own Public Key Certificate (PKC) which is issued by their own Certificate Authority (CA), the MN and the MAP authentication can be mutually achieved thorough the confidential relationship between their CAs. And the MAP can control services for the MNs based on their service profiles which is described in its attribute certificate (AC). This architecture allows the range of HMIPv6 service to be expanded and enables MNs to move between various networks, including service provider networks, enterprise networks, and home networks. 1. Introduction There is increasing demand for an ubiquitous IP service as a next generation IP service, where IP communication is possible anytime, anywhere, and with anybody. In the ubiquitous network, IP addresses will be assigned to various devices (nodes), which will be able to move freely. To achieve mobility at the IP layer, the Internet Engineering Task Force (IETF) has been developing Mobile IPv6 (MIPv6) technology [MIPv6], which allows nodes to maintain connectivity while moving. Since MIPv6 technology manages movement at the IP level, it does not depend on either applications or technologies at layer 2 or lower. By managing the current location of a mobile node (MN) in terms of a care-of address (CoA) and its home address (HoA), a home agent (HA) can seamlessly transfer IP packets to the mobile user through any kind of high-speed wireless or wired access network. To deploy the mobile IP service widely, the Hierarchical Mobile IPv6 (HMIPv6) technology [2] is also being studied in IETF. By adding a mobility anchor point (MAP) in a visited network to manage local mobility there, we can limit HAs to providing only global or inter- MAP mobility management. This technology lets us to avoid frequent location registration of MNs with HAs, which may be a long way from the MNs, and to reduce the time required for handovers. In order to deploy HMIPv6 technology, from the viewpoint of security and scalability, we must establish the mechanism which enables MNs and MAPs to set up secure communication dynamically. In this draft, Section 2 describes security issues when deploying HMIPv6 technology. Section 3 proposes a new network architecture which can provide scalable and secure HMIPv6 services. Section 4 mizuno, et al. [Page 2] Internet Draft HMIPv6-PKI October 2003 proposes an additional improvement of the proposed new network architecture. 2. Security issues in the HMIPv6 technology To deploy the HMIPv6 technology in service networks, we must establish the mechanism which enables secure MNs and secure MAPs to set up secure communication dynamically because malicious MAPs or malicious MNs might exist in the Internet. The secure communication between a MN and a MAP might not be established if there was no way of dynamic mutual authentication method. In order to solve this issue, authentication information is necessary to establish the secure communication between a MN and a MAP. Thus it is important to consider how to hold authentication information with scalability. For example, it is not scalable that a MAP holds the authentication information for all MNs in advance because the MAP must hold authentication information whenever new MNs are installed. Thus, architecture must be required to solve these issues with scalability for deploying the HMIPv6 technology. 3. HMIPv6-PKI protocol 3.1. Overview of HMIPv6-PKI protocol A new network architecture for setting up the secure communication dynamically is needed in the HMIPv6 technology. In other words, a scalable mutual authentication method must be realized in the HMIPv6 service network architecture. IPsec [3] technology is effective for the mutual authentication method. But pre-sharing and manual configuration of IPsec security associations (SAs) is not scalable because a MAP must hold IPsec SAs for all MNs in advance. Thus, we should use internet key exchange (IKE)[4] mechanism to establish the IPsec SAs dynamically because a MN and a MAP need not to share IPsec SAs in advance. In the IKE procedure, an ISAKMP[5] SA is needed for establish IPsec SAs. As the method for establishing ISAKMP SAs, the digital signature method based on the CA model (PKI) is used. In this method, the mutual authentication between a MN and a MAP is realized by verifying a communication partner's digital signature and its public key certificate (PKC) [6]. The digital signature and the PKC are exchanged in the IKE procedure. Concretely, a MN and a MAP holds a key pair. One is a private key and the other is a public key. The digital signature, which is hashed and encoded data by the private key, can be verified by only the sender's public key in the PKC. The PKC is issued by a certificate authority (CA) and identifies the owner of the public key. The CA's digital signature in the PKC can be decoded only by the CA's public key. If this decoded data is equal to the hashed data of the contents of the PKC, the PKC can be mizuno, et al. [Page 3] Internet Draft HMIPv6-PKI October 2003 verified and the public key's owner can be identified. In this method, the MN and the MAP need not share any keys and they are only needed to hold their own private key and their own PKC in advance. But if a MN's PKC and a MAP's PKC are issued by the different CA, the mutual authentication between the MN and the MAP cannot be succeeded because the MAP cannot verify the MNs' PKC, and vice versa. In other word, the mutual authentication cannot be succeeded because the MN and the MAP trusts only the CA that issued it's own PKC. In such situation, the MN and the MAP must hold all CAs' PKCs including newly installed ones beforehand for the mutual authentication between them (i.e., the MN and the MAP must trust all CAs in the HMIPv6 service network). From the viewpoint of scalability, we must improve this point. The improvement must enable a MAP to verify a MN's PKC by using CA's PKC which the MAP trusts. And the improvement must enable a MAP to dynamically obtain the CA's PKC for the verification of a MN's PKC. The former improvement can be realize by using a cross- certification mechanism, and the latter one can be realize by introducing a repository. In this method, the owner of a CA's public key can be identified by the PKC issued by another CA (i.e., cross-certificate). We apply this cross-certificate mechanism to the mutual authentication between a MN and a MAP. And we also introduce a repository which is located in the IP network and storing certificates. The mutual authentication procedure by using this method 2 is as follows; The CA-1 issues the CA-2's PKC and register to the repository, and vice versa, in advance. The CA-1 issues a MNs' PKC. And also the CA-2 issues a MAPs' PKC. Figure 1 shows possible network configuration of this proposal. The authentication sequence in the case that a MAP authenticates a MN is shown in Figure 2. This architecture enables the MAP to verify the MN's PKCs without holding the CA-1's PKC in advance. The MAPs can achieve the CA-1's PKC dynamically from the repository when it is needed. And the MAP can verify the CA-1's PKC by using the CA-2's PKC (the MAP trusts CA-2). This method has the following features; -Security for IKE The IKE messages cannot be altered by the digital signature method based on the CA model (PKI). -Validity The validity of a MAP and a MN is really confirmed because the CA guarantees the public key's owner. -Scalability MNs and MAPs can increase independently of each other, because they mizuno, et al. [Page 4] Internet Draft HMIPv6-PKI October 2003 may hold only their own PKCs. -Processing performance The high performance processing for the verifications of the digital signatures may be required if the confidential relationships between the CAs are complicated. 3.2. MAP operation When a MAP receives the IKE phase1 first packet including certificate request payload from a MN, the MAP MUST sends it's digital signature and it's PKC to the MN. The MAP receives the MN's digital signature and the MN's PKC in the third packet of IKE phase 1. The MN's digital signature MUST be verified by the MN's public key in the MN's PKC. And the CA-1's digital signature in the MN's PKC MUST be verified by the CA-1's public key in the CA-1's PKC. If the MAP does not hold the CA-1's PKC, the MAP needs to achieve the CA-1's PKC from a repository. This situation will be raised in the case that the MAP trusts only CA-2 and CA-2 trusts CA-1. All these verification by the MAP are succeeded, the MAP processes IKE phase 2 first packet from the MN. After the MN and the MAP establish the ISAKMP SA and the IPsec SA, The MN will send a local BU to the MAP with the M and A flags set. The following process is identical to the MAP operation described in [HMIPv6]. 3.3. MN operation When a MN turns on in a MAP domain or moves into a new MAP domain, the MN configures an RCoA and an LCoA. After these configurations, the MN initiates the IKE procedure for the mutual authentication between the MAP. The MN receives the MAP's digital signature and the MAP's PKC in the second packet of IKE phase 1. The MAP's digital signature MUST be verified by the MAP's public key in the MAP's PKC. And the CA-2's digital signature in the MAP's PKC MUST be verified by the CA-2's public key in the CA-2's PKC. If the MN does not hold the CA-2's PKC, the MN need to achieve the CA-2's PKC from a repository. This situation will be raised in the case that the MN trusts only CA-1 and CA-1 trusts CA-2. All these verification by the MN are succeeded, the MN initiates IKE phase 2. After the MN and the MAP establish the ISAKMP SA and the IPsec SA, the MN sends a local BU to the MAP with the A and M flags set. The following operation is identical to the MN operation described in [HMIPv6]. 3.4. HA operation mizuno, et al. [Page 5] Internet Draft HMIPv6-PKI October 2003 The support of HMIPv6-PKI protocol is completely transparent to the HA's operation. Packets addressed to a MN's HoA will be forwarded by the HA to its RCoA as described in [MIPv6]. (PKI support in MIPv6 is described in Appendix A) 3.5. CN operation HMIPv6-PKI is completely transparent to CNs. service network A service network B | +------+ | +------+ | CA-1 | | | CA-2 | +------+ | +------+ . | . . | . +------------+ | +------------+ | Repository | | | Repository | +------------+ | +------------+ | +----+ | +-----+ | HA | | | MAP | +----+ | +-----+ | | <= mutual authentication +----+ | +----+ | MN |====roaming======>| MN | +----+ | +----+ | Figure 1. network configuration for the HMIPv6-PKI architecture mizuno, et al. [Page 6] Internet Draft HMIPv6-PKI October 2003 MN MAP Repository | IKE phase 1 | | |[exchange digital signature and PKC] | |<------------------------->| | | +-----------------------------+ | | | MAP verifies MN's digital | | | | signature by using MN's PKC | | | +-----------------------------+ | | | LDAP search | | [MAP gets CA's PKC which issued MN's PKC] | | |<------------------------->| | +--------------------------+ | | | MAP verifies MN's PKC by | | | | using CA-1's PKC | | | +--------------------------+ | | | | | +--------------------------+ | | | MAP verifies CA-1's PKC | | | | by using CA-2's PKC | | | +--------------------------+ | | IKE phase 2 | | | [IPsec SA negotiation] | | |<------------------------->| | | | | | Local Binding Update (applied IPsec) | |-------------------------->| | | | | | Binding Acknowledgement (applied IPsec) | |<--------------------------| | | | | Figure 2. authentication sequence 4. Additional improvement for the proposed network architecture In the network architecture proposed in Section 3, the secure communication between a MN and a MAP can be established dynamically. In other words, we can realize the scalable mutual authentication between them. But a MAP cannot always authorize a MN to use the services because the MAP can only identify the public key's owner by using the mutual authentication method. For example, the MAP cannot authorize whether a roaming service may be offered to the MN or not only by using the PKC. So, we need to realize the service authorization method so that the MAP can authorize the MN to be offered the roaming services based on a MNs' service profile (In the MN's service profile, what kind of services the MN can be offered should be defined.). The network architecture proposed in Section 3 enables MNs to roam holding only its own PKC in advance. But the service authorization method using only this PKC has the following mizuno, et al. [Page 7] Internet Draft HMIPv6-PKI October 2003 issues; - There is no field suitable for describing a service profile because a PKC is supposed to be used to identify only the public key's owner. - If we might describe a MN's service profile in a PKC, frequent updating the contents of the PKC whenever the service profile changes raised the operational cost because a PKC is issued to the user based on a strict identification (so PKC is usually valid for years). - Complicated maintenance of a certificate revocation list (CRL)[6] is required if the PKC needs to be revoked while it is valid. Then, we propose to apply an attribute certificate (AC) [7]. An AC is issued by an attribute authority (AA)[7] and guarantees the attribute of the public key's owner. The AC enables a MAP to decide whether the roaming service may be offered to the MN or not based on the attribute (i.e., service profile) in it. Figure 3 shows possible network configuration of this proposal. The sequence used in this method is shown in Figure 4. Concretely, in addition to the mutual authentication described in Section 3, the CA-1 located in the service network A also issues AA's PKC. Then, the AA-1 in the service network A issues the MNs' AC whose contents are the service profiles of the MNs and the AA-1 registers the AC to the repository. After the mutual authentication between the MN and the MAP by using the PKC, the MAP achieves the MNs' AC from the repository. The linkage between the MN's PKC and its AC can be obtained by using distinguished name or serial number in the MN's PKC. This proposed method enables the MAP to offer the roaming service only to users who contracted for it. The features of the PKC and the AC are as follows; [The feature of the PKC] -Purpose Identify the owner of the public key -Contents Semi-permanent information which can specify the public key's owner (e.g., name, gender, address). -Valid lifetime Long term (generally valid in years) -Scope Global networks -Organization Certificate Authority (CA) [The feature of the AC] mizuno, et al. [Page 8] Internet Draft HMIPv6-PKI October 2003 -Purpose Guarantee the attribute of the public key's owner -Contents Attribute information that is changed in the short term (e.g., company or project name). -Valid lifetime Short term if needed -Scope Restricted segments where AA is deployed -Organization Attribute Authority (AA) service network A service network B | +----+ +------+ | +------+ | AA | | CA-1 | | | CA-2 | +----+ +------+ | +------+ . . | . . . | . +------------+ | +------------+ | Repository | | | Repository | +------------+ | +------------+ | +----+ | +-----+ | HA | | | MAP | <= service authorization +----+ | +-----+ | | <= mutual authentication +----+ | +----+ | MN |====roaming======>| MN | +----+ | +----+ | Figure 3. network configuration for the enhanced HMIPv6-PKI architecture mizuno, et al. [Page 9] Internet Draft HMIPv6-PKI October 2003 MN MAP Repository | IKE phase 1 | | |[exchange digital signature and PKC] | |<------------------------->| | | +-----------------------------+ | | | MAP verifies MN's digital | | | | signature by using MN's PKC | | | +-----------------------------+ | | | LDAP search | | [MAP gets CA's PKC which issued MN's PKC] | | |<------------------------->| | +--------------------------+ | | | MAP verifies MN's PKC by | | | | using CA-1's PKC | | | +--------------------------+ | | | | | +--------------------------+ | | | MAP verifies CA-1's PKC | | | | by using CA-2's PKC | | | +--------------------------+ | | | LDAP search | | |[MAP gets MN's AC and AA's | | PKC which is issued MN's AC] | |<------------------------->| | +-----------------------------+ | | | MAP verifies MN's AC by | | | | using AA's PKC | | | +-----------------------------+ | | | | | +-----------------------------+ | | | MAP verifies AA's PKC by | | | | using CA-1's PKC | | | +-----------------------------+ | | | | | +--------------------------------+ | | | MAP authorize MN to be offered | | | | service based on the contents | | | | of MN's AC | | | +--------------------------------+ | | IKE phase 2 | | | [IPsec SA negotiation] | | |<------------------------->| | | | | | Local Binding Update (applied IPsec) | |-------------------------->| | | | | | Binding Acknowledgement (applied IPsec) | |<--------------------------| | Figure 4. authentication and authorization sequence mizuno, et al. [Page 10] Internet Draft HMIPv6-PKI October 2003 References [1] David B. Johnson et al., Mobility Support in IPv6h, draft-ietf- mobileip-ipv6-24.txt, June 2003. [2] Hesham Soliman et al.,Hierarchical Mobile IPv6 mobility management (HMIPv6), draft-ietf-mobileip-hmipv6-08.txt, June 2003. [3] RFC2401, gSecurity Architecture for the Internet Protocolh, Nov.1998. [4] RFC 2409, gThe Internet Key Exchange (IKE)h, Nov. 1998. [5] RFC2408, gInternet Security Association and Key Management Protocol (ISAKMP)h, Nov. 1998. [6] RFC3280, gInternet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002. [7] RFC3281, gAn Internet Attribute Certificate Profile for Authorizationh, April 2002. Appendix A In this draft, we propose the scalable and secure HMIPv6 service network architecture. In this network architecture, the latest PKI technology is used as the scalable mutual authentication method between a MN and a MAP. By using the PKI technology, the MN and the MAP need not share any keys and they are only needed to hold their own private key and their own PKC for the mutual authentication between them. This authentication method can be used not only between the MN and the MAP but also between the MN and it's HA, and at a wireless access network (e.g., IEEE 802.1x EAP-TLS). If this method is used in the MIPv6 authentication and the authentication at the wireless access network, the usability of the user will progress because the user can use the HMIPv6 service (including MIPv6 service and network access service) by holding only one PKC. Furthermore, other IP services, that are expected to use the PKI technology as the authentication method, will increase. The usability of users will progress further because this authentication method makes it possible that the MN can use various IP services by holding only one PKC. On the other hand, nowadays, users' authentication information or service authorization information will be maintained dispersedly in the IP network because service nodes (e.g., SIP server, web server) will intend to be located dispersedly. In such situation, a network service provider is hard to manage users' authentication information mizuno, et al. [Page 11] Internet Draft HMIPv6-PKI October 2003 or service authorization information. By using the proposed architecture, authentication information and service authorization information can be achieved by using a distinguished name (DN) which is described in the holder field of a PKC and an AC as the user identification information. Author's Address Shiro Mizuno NTT Network Systems Laboratories, NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6965 EMail: mizuno.shiro@lab.ntt.co.jp Junichi Koga NTT Network Systems Laboratories, NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6979 EMail: koga.junichi@lab.ntt.co.jp Hidenari Ohwada NTT Network Systems Laboratories, NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6981 EMail: ohwada.hidenari@lab.ntt.co.jp Kazuhiko Suzuki NTT Network Systems Laboratories, NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 3458 EMail: suzuki.kazuhiko@lab.ntt.co.jp Yasushi Takagi NTT Network Systems Laboratories, NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6059 EMail: takagi.yasushi@lab.ntt.co.jp mizuno, et al. [Page 12]