Network Working Group J. Arkko INTERNET-DRAFT R. Blom Category: Informational Ericsson 27 May 2002 The MAP Security Domain of Interpretation for Internet Security Association and Key Management Protocol Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026 [STDS]. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and 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. To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Australia), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). The distribution of this memo is unlimited. It is filed as , and expires November 27, 2002. Please send comments to the authors. 1. Abstract The Mobile Application Part (MAP) protocol is a signaling protocol for cellular networks. The MAP Security (MAPSEC) protocol provides a secure way to transport MAP messages. To use MAPSEC, however, Security Associations (SAs) are needed. This document defines how such SAs can be created automatically. We use the Internet Security Association and Key Management Protocol (ISAKMP) as a framework for managing SAs and establishing keys. The framework can be specialized to a particular task. Such a specialization is called a Domain of Interpretation (DOI), and this document defines Arkko & Blom Informational [Page 1] INTERNET-DRAFT MAPSEC DOI 27 May 2002 the MAPSEC DOI. This specialization is very similar to the Internet Key Exchange protocol and the ISAKMP specialization for IP Security, except that non-IP protocols are being negotiated. Contents 1. Abstract 2. Terms and Definitions 3. Introduction 3.1. MAP and MAPSEC 3.2. Domains of Interpretation 3.3. Network Architecture 4. MAPSEC DOI Phase 1 4.1 MAPSEC DOI Number 5. MAPSEC DOI Phase 2 5.1 Naming Scheme 5.2 MAPSEC Situation Definition 4.2.1 SIT_IDENTITY_ONLY 5.3 MAPSEC Policy Requirements 5.4 MAPSEC Assigned Numbers 5.4.1 MAPSEC Security Protocol Identifier 4.5.1.1 PROTO_MAPSEC 5.4.1 MAPSEC Transform Identifiers 5.5 MAPSEC Security Association Attributes 5.5.1 Required Attribute Support 5.5.2 Attribute Negotiation 5.5.3 Lifetime Matching 5.6 MAP Security Payload Content 5.6.1 Identification Payload Content 5.6.2 Notify Message Types 5.7 MAPSEC Key Exchange Requirements 6. Security Considerations 7. IANA Considerations 7.1 MAPSEC Situation Definition 7.2 MAPSEC Security Protocol Identifiers 7.3 MAPSEC MAP Security Transform Identifiers 7.4 MAPSEC Security Association Attributes 7.5 MAPSEC Identification Type 8. Key Derivation for MAP Security 9. Intellectual property rights 10. Acknowledgments 11. References 11.1 Normative References 11.2 Informative References 12. Author's Address 2. Terms and Definitions Arkko & Blom Informational [Page 2] INTERNET-DRAFT MAPSEC DOI 27 May 2002 In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [WORDS]. 3. Introduction 3.1. MAP and MAPSEC In the Global Mobile System (GSM) and Universal Mobile Telecommunication System (UMTS) networks, the MAP protocol plays a central role in the signaling communications between the Network Elements (NEs). User profile exchange, authentication, and mobility management are performed using MAP. MAP runs typically over the Signaling System number 7 (SS7) protocol stack. For a full description of the MAP protocol, see [MAP]. The mobile networks are moving to IP-based solutions. Completely IP-based networks and new signaling protocols will replace MAP at some point. However, MAP and SS7 signaling networks have to be supported during the transition time, and beyond, due to the need to retain legacy equipment in networks. MAP has a role in the authentication process of GSM phones, and operators are concerned about its lack of cryptographic security support. For this reason a new protocol header has been developed to protect MAP messages, much in the same way as the Encapsulating Security Payload (ESP) protocol protects IP packets. This new protocol is called MAPSEC [NDSEC]. A key management mechanism is also needed for MAPSEC. This key management mechanism runs over IP. 3.2. Domains of Interpretation The Internet Security Association and Key Management Protocol (ISAKMP) provides a common framework for protocols that manage Security Associations (SAs) and establish keys. This framework may be specialized to different tasks, with different requirements and security properties. Each such specialization results in a new task-specific protocol. ISAKMP provides a common message format for these protocols. A specialization of ISAKMP is called a Domain of Interpretation (DOI). A DOI defines the interpretation of task-specific parts in ISAKMP messages. These parts include the fields which are used to inform the peer about the supported cryptographic algorithms and protocols, and the fields which are used to carry the identities of Arkko & Blom Informational [Page 3] INTERNET-DRAFT MAPSEC DOI 27 May 2002 the parties. As ISAKMP is used in different tasks, the required algorithms and other parameters may be different. For instance, the IP Security DOI [IPSDOI] describes the use of ISAKMP in the context of IP Security protocols (AH, ESP) and IP Compression. The Internet Key Exchange (IKE) protocol uses IP Security DOI. The IKE protocol, and the parameters of the DOI are divided in two phases: In Phase 1, an authentication is performed and protection for ISAKMP itself is set up. In Phase 2, actual AH and ESP SAs are negotiated. This document defines the MAPSEC DOI for ISAKMP. This DOI can be used to negotiate MAPSEC SAs. Phase 1 related issues for the MAPSEC DOI are described in Section 4. Phase 2 related issues are described in Section 5. In addition, 3GPP Technical Specifications [NDSEC] specify the actual MAPSEC authentication and encryption algorithms and the so called protection profiles. [NDSEC] defines also the values that are used in the MAPSEC DOI to refer to these algorithms and profiles. This ensures that the MAPSEC DOI document does not have to be modified upon the development of a new authentication algorithm, for instance. This new DOI is very similar to the IP Security DOI and IKE. The only technical differences are with respect to the Phase 2, otherwise a subset of the IP Security DOI and IKE is used. MAPSEC DOI is separated from IKE as a new DOI rather than an extension of the current one in order to allow the two protocols to have different port numbers, name spaces, and change control in the future. If IKE is developed further or replaced by new protocols, it is possible to update the MAPSEC DOI to use a new protocol. Such an update would involve extending the new protocol to allow other protocols than AH and ESP, and allowing certain new algorithm identifiers and other parameters. 3.3. Network Architecture The MAP Security protocol and its key management part provide authentication, confidentiality, integrity, and replay protection services to the MAP messages it transports. The purpose of the MAP Security header in the protocol is to provide enough information to determine the MAP Security Association and Protection Modes used in securing the MAP operation that follows the header. MAPSEC DOI and IKE are used to set up SAs for nodes implementing Arkko & Blom Informational [Page 4] INTERNET-DRAFT MAPSEC DOI 27 May 2002 MAPSEC. While the MAP protocol usually runs over SS7, the MAPSEC DOI and IKE are always run over IP. Therefore, it is assumed that nodes or networks implementing MAPSEC always have IP connectivity in addition to SS7 connectivity. Figure 1 below depicts the situation. _---------MAPSEC key management over IP-------_ / \ | | +-----------+ +-----------+ | | | | | Node or | | Node or | | Network 1 |---------MAPSEC over SS7---------| Network 2 | | | | | | | | | +-----------+ +-----------+ Figure 1: Network architecture for MAP Security The network architectures where the MAPSEC DOI can be run include but are not limited to the one defined by 3GPP [NDSEC]. In the 3GPP architecture the MAPSEC is typically run between two different network operators, and the same SAs are shared by a number of NEs. As in IKE, the MAPSEC DOI allows only symmetric SAs to be set up. That is, a pair of SAs is always created for the incoming and outgoing directions. These SAs differ only with respect to the keys, SPIs, and peer identities but all other parameters including the algorithms will have the same values. 4. MAPSEC DOI Phase 1 For Phase 1, all IP Security DOI definitions [IPSDOI] and IKE procedures [ISAKMP, IKE] MUST be used unchanged in the MAPSEC DOI, including the way that peers are authenticated. However, with the MAPSEC DOI the following exceptions to the full requirements will apply: o All MAPSEC DOI communications SHOULD run on port TBD instead of the standard IKE port 500. This applies to both Phase 1 and 2. Additionally, MAPSEC DOI implementations MUST send the value zero in the port field of the identity payload during Phase 1 (standard IKE allows either 0 or 500). o Support for Perfect Forward Secrecy (PFS) is not required. An implementation that receives a Phase 2 negotiation request with PFS on MAY decline the negotiation. Arkko & Blom Informational [Page 5] INTERNET-DRAFT MAPSEC DOI 27 May 2002 o Only one identity type, ID_FQDN, MUST be implemented for Phase 1. Other identity types specified in [IPSDOI] SHOULD be implemented. o Only the AES encryption [AESESP] and SHA-1 hash [IKE] algorithms MUST be implemented as ISAKMP encryption and hash operations. Implementer's note: IKE [IKE] specifies that all implementations MUST support authentication through pre-shared secrets and SHOULD support public key based authentication. All implementations also MUST support Main Mode. 4.1 MAPSEC DOI Number Within ISAKMP, all DOI's MUST be registered with the IANA. This number is TBD. 5. MAPSEC DOI Phase 2 IKE procedures regarding Phase 2 are used unchanged, with the following exceptions: o Identity types used in Phase 2 are different. o SA payloads are different. o There are no MAPSEC-specific Phase 2 notifications. Note also that all implementations of this DOI MUST be able to handle the deletion of an existing SA (allowed also by IKE). 5.1 Naming Scheme Within the MAPSEC DOI, all well-known identifiers MUST be registered as explained in Section 7. All multi-octet binary values are stored in network byte order. 5.2 MAPSEC Situation Definition Within ISAKMP, the Situation field provides information that can be used by the responder to make a policy determination about how to process the incoming negotiation request. For the MAPSEC DOI, the Situation field in Phase 1 is handled as specified by the IP Security DOI [IPSDOI]. In Phase 2, the Situation field is a four (4) octet bitmask with the following value: Arkko & Blom Informational [Page 6] INTERNET-DRAFT MAPSEC DOI 27 May 2002 Situation Value --------- ----- SIT_IDENTITY_ONLY 0x01 5.2.1 SIT_IDENTITY_ONLY The SIT_IDENTITY_ONLY type specifies that the SA will be identified by source identity information present in an associated Identification Payload. See Section 5.6.1 for a complete description of the various Identification types. All MAPSEC DOI implementations MUST support SIT_IDENTITY_ONLY by including two Identification Payloads in the Phase 2 exchange, and MUST abort any negotiation that fails to do so. 5.3 MAPSEC Policy Requirements The policy requirements for nodes implementing the MAPSEC DOI are beyond the scope of this document. However, it is required that systems are able to specify their policies with respect to the MAP traffic in terms of Protection Profiles as defined in [NDSEC]. These Protection Profiles indicate the need for a particular kind of protection based on the type of the MAP message. For the purposes of this document a Protection Profile is a 16 bit number that is agreed during the SA negotiation. 5.4 MAPSEC Assigned Numbers The following sections list the Assigned Numbers for the MAPSEC DOI. Sections 5.4.1 to 5.5 describe Protocol Identifiers, MAPSEC Transform Identifiers and Security Association Attribute Type Values, which are a part of the MAPSEC SA Payloads. Section 5.6 describes ID Payload Type Values and Notify Message Type Values. These are ISAKMP payloads whose data representations depend on the applicable DOI. 5.4.1 MAPSEC Security Protocol Identifier The ISAKMP proposal syntax was specifically designed to allow for the simultaneous negotiation of multiple Phase 2 security protocol suites within a single negotiation. As a result, the protocol suites listed below form the set of protocols that can be negotiated at the same time. The combination of protocol suites that may be negotiated together is a host policy decision. The following table lists the values for the Security Protocol Identifiers referenced in an ISAKMP Proposal Payload for the MAPSEC DOI. Arkko & Blom Informational [Page 7] INTERNET-DRAFT MAPSEC DOI 27 May 2002 Protocol ID Value ----------- ----- RESERVED 0-1 PROTO_MAPSEC TBD 5.4.1.1 PROTO_MAPSEC The PROTO_MAPSEC type specifies the use of the MAP Security to protect MAP messages. 5.4.2 MAPSEC Transform Identifiers The following table lists the reserved MAPSEC Transform Identifiers. Transform ID Value ------------ ----- RESERVED 0-1 Actual MAP Transform Identifiers are defined in the 3GPP Technical Specification [NDSEC]. 5.5 MAPSEC Security Association Attributes The following SA attribute definitions are used in Phase 2 of an IKE negotiation. Attribute types can be either Basic (B) or Variable-Length (V). Encoding of these attributes is defined in the base ISAKMP specification. Attributes defined as Basic MUST NOT be encoded as Variable-Length. Variable-Length attributes MAY be encoded as Basic attributes if their value can fit into two octets. See [IKE] for further information on attribute encoding in the MAPSEC DOI. All restrictions listed in [IKE] also apply to the MAPSEC DOI. Implementer's note: The attributes described here behave exactly as the corresponding ones in the IP Security DOI, unless otherwise explicitly specified. For the purposes of reusing IP Security DOI code, the parameters not used by MAPSEC DOI are defined as class RESERVED (values 4, 8, and 9). Attribute Types class value type ------------------------------------------------- SA Life Type 1 B SA Life Duration 2 V Group Description 3 B Arkko & Blom Informational [Page 8] INTERNET-DRAFT MAPSEC DOI 27 May 2002 RESERVED 4 - Authentication Algorithm 5 B Key Length 6 B Key Rounds 7 B RESERVED 8 - RESERVED 9 - MAP Protection Profile 100 B MAP PP Version Indicator 101 B Class Definitions SA Life Type SA Duration Specifies the time-to-live for the SA. When the SA expires, the SA MUST be renegotiated. MAPSEC messages using the expired SA MUST no longer be either sent or accepted as input. The life type values are: RESERVED 0 seconds 1 RESERVED 2 For a given Life Type, the value of the Life Duration attribute defines the actual length of the component lifetime -- in seconds. If unspecified, the default value MUST be assumed to be 28800 seconds (8 hours). The SA Life Duration attribute MUST always follow the SA Life Type describing the units of duration. Implementer's note: The semantics and values for these attributes are exactly as defined in [IPSDOI], except that kilobyte lifetimes are not supported. Group Description Specifies the Oakley Group to be used in a PFS QM negotiation. For a list of supported values, see Appendix A of [IKE]. Implementer's note: The semantics and values for these attributes are exactly as defined in [IPSDOI]. Authentication Algorithm RESERVED 0-4 Arkko & Blom Informational [Page 9] INTERNET-DRAFT MAPSEC DOI 27 May 2002 This specification only lists the reserved values. Actual Authentication Algorithm values are defined in the 3GPP Technical Specification [NDSEC]. There is no default value for Authentication Algorithm. It MUST be always sent. Implementer's note: The first five values are reserved by the IP Security DOI. Key Length RESERVED 0 There is no default value for Key Length. This attribute MUST be sent for transforms that use ciphers with variable key lengths. For fixed length ciphers, the Key Length attribute MUST NOT be sent. The definition of MAPSEC transforms in the 3GPP Technical Specifications such as [NDSEC] MUST specify if the use of Key Length is necessary and what the legal values are. Implementer's note: The semantics and values for these attributes are exactly as defined in [IPSDOI]. Key Rounds RESERVED 0 There is no default value for Key Rounds, as it must be specified for transforms using ciphers with varying numbers of rounds. Implementer's note: The semantics and values for these attributes are exactly as defined in [IPSDOI]. MAP Protection Profile The value of this attribute is a 16-bit entity as defined in [NDSEC]. MAP PP Version Indicator The Protection Profile Version Indicator allows different versions of protection profiles to be used. The value of this attribute is a 16-bit entity as defined in [NDSEC]. 5.5.1 Required Attribute Support Arkko & Blom Informational [Page 10] INTERNET-DRAFT MAPSEC DOI 27 May 2002 To ensure basic interoperability, all implementations MUST be able to negotiate all of the following attributes: SA Life Type SA Duration Authentication Algorithm Key Length MAP Protection Profile MAP PP Version Indicator 5.5.2 Attribute Negotiation If an implementation receives a defined MAPSEC DOI attribute (or attribute value) which it does not support, an ATTRIBUTES-NOT- SUPPORTED Notification Payload SHOULD be returned and the negotiation MUST be aborted, unless the attribute value is in the reserved range. If an implementation receives an attribute value in the reserved range, an implementation MAY choose to continue based on local policy. Implementer's note: This follows exactly the IP Security DOI. However, there are no special lifetime attribute parsing requirements, since only time-based lifetimes are supported. 5.5.3 Lifetime Matching Offered and locally acceptable SA lifetimes must match exactly under MAPSEC in order for the responder to select an SA. Implementer's note: This is simplified from the IP Security DOI which required notifications. In the MAPSEC DOI lifetime notifications are not defined and hence not used. 5.6 MAP Security Payload Content The SA Payloads that the Initiator and the Responder exchange control the SAs that actually get installed. The attributes discussed above are a part of the SA Payloads. For a definition of a MAPSEC SA, see [NDSEC]. The following sections describe those ISAKMP payloads whose data representations are dependent on the applicable DOI. 5.6.1 Identification Payload Content The initiator of the negotiation is identified using the Arkko & Blom Informational [Page 11] INTERNET-DRAFT MAPSEC DOI 27 May 2002 Identification Payload. The responder SHOULD use the initiator's identity to determine the correct security policy for creating SAs. During Phase 1, the ID port and protocol fields MUST be set to zero or to the UDP port that the MAPSEC DOI is running on. If an implementation receives any other values, this MUST be treated as an error and the negotiation MUST be aborted. The following diagram illustrates the content of the Identification Payload. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! Protocol ID ! Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Identification Payload Format The Identification Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the type of the next payload in the message. If the current payload is the last in the message, this field will be zero (0). o RESERVED (1 octet) - Unused, must be zero (0). o Payload Length (2 octets) - Length, in octets, of the identification data, including the generic header. o Identification Type (1 octet) - Value describing the identity information found in the Identification Data field. o Protocol ID (1 octet) - Value specifying an associated Transport Layer Protocol ID (e.g. UDP/TCP). Value zero means that the Protocol ID field should be ignored. In the MAPSEC DOI Phase 2, the Protocol field MUST always be zero (0). o Port (2 octets) - Value specifying an associated port. A value of zero means that the Port field should be ignored. In the MAPSEC DOI, value of zero MUST always be used in Phase 2. Unlike in IP traffic protected by IP Security, the concept of a port is not used in MAP. Arkko & Blom Informational [Page 12] INTERNET-DRAFT MAPSEC DOI 27 May 2002 o Identification Data (variable length) - Value, as indicated by the Identification Type. The legal Identification Type field values in Phase 1 are as defined in [IPSDOI]. Phase 2 identities MUST conform to the following table. The table lists the assigned values for the Identification Type field found in the Identification Payload. (Values from 0 to 11 are reserved by the IP Security DOI for the purposes of code reuse.) ID Type Value ------- ----- RESERVED 0-11 ID_PLMN_ID 12 In MAPSEC DOI, the ID_PLMN_ID type specifies PLMN ID of the Initiator or the Responder. The PLMN ID MUST be represented as defined in section 17.7.8 of [MAP], i.e. as a three octet data item with the Mobile Country Code (MCC) followed by the Mobile Network Code (MNC). The size of the PLMN ID MUST correspond to the size in the ID payload header. 5.6.2 Notify Message Types There are no DOI-specific Notify Message types for the MAPSEC DOI in Phase 2. Note however that Phase 1 uses the standard ISAKMP and IP Security DOI notifications that are defined in section 3.14.1 of [ISAKMP] and section 4.6.3 of [IPSDOI], respectively. Even Phase 2 of the MAPSEC DOI uses standard ISAKMP notifications. Implementer's note: The reason why MAPSEC DOI does not need the same Phase 2 DOI-specific notifications is the following. MAPSEC does not allow turning replay protection on or off, which makes the use of REPLAY-STATUS unnecessary. Responder lifetimes are required to be exactly the same as the initiator lifetimes, which makes the use of RESPONDER-LIFETIME unnecessary. INITIAL-CONTACT notification on the other hand is used exclusively in Phase 1, and is therefore applicable also for MAPSEC DOI in Phase 1. 5.7 MAPSEC Key Exchange Requirements The MAPSEC DOI introduces no additional Key Exchange types. 6. Security Considerations This entire memo relates to the Internet Key Exchange protocol Arkko & Blom Informational [Page 13] INTERNET-DRAFT MAPSEC DOI 27 May 2002 ([IKE]), which combines ISAKMP ([ISAKMP]) and Oakley ([OAKLEY]) to provide the derivation of cryptographic keying material in a secure and authenticated manner. Specific discussion of the various security protocols and transforms identified in this document can be found in the associated base documents and in the cipher references. 7. IANA Considerations This document contains many parameters to be maintained by the the standardization bodies. In the case of the MAPSEC DOI, 3GPP will assign many of the parameters normally maintained by IANA. This section explains how 3GPP will assign new values for different MAPSEC DOI related parameters. All values not explicitly defined in previous sections will be assigned by 3GPP. IANA will still define the DOI numbers, including the DOI number for this DOI. 7.1 MAPSEC Situation Definition The Situation Definition is a 32-bit bitmask which represents the environment under which the MAPSEC SA proposal and negotiation is carried out. Requests for new Situation Definition values must be accompanied by a 3GPP Technical Specification which describes the new Situation. The upper two bits are reserved for private use between cooperating systems. 7.2 MAPSEC Security Protocol Identifiers The Security Protocol Identifier is an 8-bit value which identifies a security protocol suite being negotiated. Requests for new security protocol identifiers must be accompanied by a 3GPP Technical Specification which describes the security protocol. The values 249-255 are reserved for private use between cooperating systems. 7.3 MAPSEC MAP Security Transform Identifiers The MAP Security Transform Identifier is an 8-bit value which identifies the algorithm to be used to protect for MAP messages. Requests for new Transform Identifiers must be accompanied by a 3GPP Technical Specification describing the use of the algorithm within the MAPSEC DOI framework. The values 249-255 are reserved for private use between cooperating systems. Arkko & Blom Informational [Page 14] INTERNET-DRAFT MAPSEC DOI 27 May 2002 7.4 MAPSEC Security Association Attributes The MAPSEC Security Association Attribute consists of a 16-bit type definition and its associated value. MAPSEC SA attributes are used to pass miscellaneous values between ISAKMP peers. Requests for new MAPSEC SA attributes must be accompanied by a 3GPP Technical Specification describing the attribute semantics, its type encoding (Basic/Variable-Length) and its legal values. Section 5.5 of this document provides an example of such a description. The values 32001-32767 are reserved for private use between cooperating systems. Requests for new values for existing attributes must be accompanied also by a 3GPP Technical Specification. Such specifications describe the semantics of the new values. 7.5 MAPSEC Identification Type The MAPSEC Identification Type is an 8-bit value which is used as a discriminant for the interpretation of the variable-length Identification Payload. Requests for new Identification Types must be accompanied by a 3GPP Technical Specification which describes how to use the identification type. The values 249-255 are reserved for private use between cooperating systems. 8. Key Derivation for MAP Security MAP Security requires two sets of keys, one for each direction, just as in the case of IP Security SAs. Separate authentication and encryption keys are also needed for each direction. For one direction, these two keys are taken from the keying material in following order: first the authentication key, and then the encryption key. The keys are derived with the procedure described in Section 5.5 of [IKE]. Implementer's note: The same procedure is used in order to simplify specification and implementation. Note also that one of the parameters needed for the derivation process is constant, i.e. the protocol is always PROTO_MAPSEC. 9. Intellectual property rights Arkko & Blom Informational [Page 15] INTERNET-DRAFT MAPSEC DOI 27 May 2002 Ericsson has patent applications which may cover parts of this technology. Should such applications become actual patents and be determined to cover parts of this specification, Ericsson intends to provide licensing when implementing, using or distributing the technology under openly specified, reasonable, non-discriminatory terms. 10. Acknowledgments This document is derived from the work done by the SA3 group of 3GPP. The authors wish to thank in particular David Castellanos- Zamora, Krister Boman, Anders Liljekvist, Eeva Munter and others at Ericsson, and Tatu Ylonen and others at SSH Communications Security Corp, Marc Blommaert, Dirk Kroeselberg, and Ulrich Wiehe at Siemens, and Olivier Paridaens at Alcatel. 11. References 11.1 Normative References [AESESP] S. Frankel, S. Kelly, R. Glenn, "The AES Cipher Algorithm and Its Use With IPsec", draft-ietf-ipsec-ciph-aes-cbc-03. txt. Work In Progress, IETF, November 2001. [AESMAC] M. Dworkin, "Recommendation for Block Cipher Modes of Operation", NIST Special Publication 800-38A, December 2001. [IKE] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [IPSDOI] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [ISAKMP] D. Maughan, M. Schertler, M. Schneider and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [MAP] 3rd Generation Partnership Project, Technical Specification Group Core Network, "Mobile Application Part (MAP) Specification (Release 5)", 3GPP TS 29.002, 2002. [NDSEC] 3rd Generation Partnership Project, Technical Specification Group SA3, Security "Network Domain Security; MAP Application Layer Security (Release 5)", 3GPP TS 33.200, 2002. [STDS] S. Bradner, "The Internet Standards Process -- Revision 3", Arkko & Blom Informational [Page 16] INTERNET-DRAFT MAPSEC DOI 27 May 2002 RFC 2026, October 1996. [WORDS] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2 Informative References [AH] S. Kent, and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [ARCH] S. Kent and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [ESP] S. Kent and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [OAKLEY] H. Orman, "The OAKLEY Key Determination Protocol", RFC 2412, November 1998. 12. Authors' Addresses Jari Arkko Oy LM Ericsson Ab 02420 Jorvas Finland Phone: +358 40 5079256 EMail: jari.arkko@ericsson.com Rolf Blom Ericsson Radio Systems AB SE-16480 Stockholm Sweden Phone: +46 8 58531707 EMail: rolf.blom@era.ericsson.se Full Copyright Statement Copyright (C) The Internet Society (1998). 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 Arkko & Blom Informational [Page 17] INTERNET-DRAFT MAPSEC DOI 27 May 2002 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. Arkko & Blom Informational [Page 18]