IP Security J. Arkko Internet-Draft R. Blom Expires: September 20, 2004 Ericsson March 22, 2004 The Mobile Application Part SECurity (MAPSEC) Domain of Interpretation (DOI) for the Internet Security Association and Key Management Protocol (ISAKMP) draft-arkko-map-doi-08 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. This Internet-Draft will expire on September 20, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. 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 the MAPSEC DOI. This Arkko & Blom Expires September 20, 2004 [Page 1] Internet-Draft MAPSEC DOI March 2004 specialization is very similar to the Internet Key Exchange protocol and the ISAKMP specialization for IP Security, except that SAs for use with non-IP protocols are being negotiated. Table of Contents 1. Terms and Definitions . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 MAP and MAPSEC . . . . . . . . . . . . . . . . . . . . 4 2.2 Domains of Interpretation . . . . . . . . . . . . . . 4 2.3 Network Architecture . . . . . . . . . . . . . . . . . 5 3. MAPSEC DOI Phase 1 . . . . . . . . . . . . . . . . . . . . . 7 3.1 MAPSEC DOI Number . . . . . . . . . . . . . . . . . . 7 4. MAPSEC DOI Phase 2 . . . . . . . . . . . . . . . . . . . . . 8 4.1 Naming Scheme . . . . . . . . . . . . . . . . . . . . 8 4.2 MAPSEC Situation Definition . . . . . . . . . . . . . 8 4.2.1 SIT_IDENTITY_ONLY . . . . . . . . . . . . . . . 8 4.3 MAPSEC Policy Requirements . . . . . . . . . . . . . . 8 4.4 MAPSEC Assigned Numbers . . . . . . . . . . . . . . . 9 4.4.1 MAPSEC Security Protocol Identifier . . . . . . 9 4.4.2 MAPSEC Transform Identifiers . . . . . . . . . . 9 4.5 MAPSEC Security Association Attributes . . . . . . . . 10 4.5.1 Required Attribute Support . . . . . . . . . . . 12 4.5.2 Attribute Negotiation . . . . . . . . . . . . . 12 4.5.3 Lifetime Matching . . . . . . . . . . . . . . . 13 4.6 SA Payload Content . . . . . . . . . . . . . . . . . . 13 4.6.1 Identification Payload Content . . . . . . . . . 13 4.6.2 Notify Message Types . . . . . . . . . . . . . . 15 4.7 MAPSEC Key Exchange Requirements . . . . . . . . . . . 15 5. Key Derivation for MAPSEC . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 7.1 MAPSEC Situation Definition . . . . . . . . . . . . . 18 7.2 MAPSEC Security Protocol Identifiers . . . . . . . . . 18 7.3 MAPSEC Transform Identifiers . . . . . . . . . . . . . 18 7.4 MAPSEC Security Association Attributes . . . . . . . . 19 7.5 MAPSEC Identification Type . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 Normative References . . . . . . . . . . . . . . . . . . . . 20 Informative References . . . . . . . . . . . . . . . . . . . 21 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . 23 Arkko & Blom Expires September 20, 2004 [Page 2] Internet-Draft MAPSEC DOI March 2004 1. Terms and Definitions 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 [9]. Arkko & Blom Expires September 20, 2004 [Page 3] Internet-Draft MAPSEC DOI March 2004 2. Introduction 2.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 typically runs over the Signaling System number 7 (SS7) protocol stack. For a full description of the MAP protocol, see [6]. 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 [7]. A key management mechanism is also needed for MAPSEC. This key management mechanism runs over IP. 2.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 the parties. As ISAKMP is used in different tasks, the required algorithms and other parameters may be different. For instance, the IP Security DOI [4] describes the use of ISAKMP in the context of IP Security protocols (AH, ESP) and IP Compression. The Internet Key Exchange (IKE) protocol uses the IP Security DOI. The IKE protocol, and the parameters of the DOI are divided in two Arkko & Blom Expires September 20, 2004 [Page 4] Internet-Draft MAPSEC DOI March 2004 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 3. Phase 2 related issues are described in Section 4. In addition, 3GPP Technical Specifications [7] specify the actual MAPSEC authentication and encryption algorithms and the so called protection profiles. Protection Profiles indicate the protection requirements for each MAP message type. [7] 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. 2.3 Network Architecture The MAP Security (MAPSEC) protocol and its key management part provide authentication, confidentiality, integrity, and replay protection services to the MAP messages it transports. The purpose of the MAPSEC header in the protocol is to provide enough information to determine the MAPSEC SA and Protection Profiles used in securing the MAP operation that follows the header. MAPSEC DOI and IKE are used to set up SAs for nodes implementing 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. Arkko & Blom Expires September 20, 2004 [Page 5] Internet-Draft MAPSEC DOI March 2004 _---------MAPSEC key management over IP-------_ / \ | | +-----------+ +-----------+ | | | | | Node or | | Node or | | Network 1 |---------MAPSEC over SS7---------| Network 2 | | | | | | | | | +-----------+ +-----------+ Figure 1: Network architecture for MAPSEC The network architectures where the MAPSEC DOI can be run includes, but are not limited to, the one defined by 3GPP [7]. 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 always establishes two simplex SAs, one for the incoming and another one for the outgoing direction. These SAs differ only with respect to the keys, SPIs, and peer identities but all other parameters including the algorithms MUST have the same values. Arkko & Blom Expires September 20, 2004 [Page 6] Internet-Draft MAPSEC DOI March 2004 3. MAPSEC DOI Phase 1 For Phase 1, all IP Security DOI definitions [4] and IKE procedures [5, 3] 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 < To Be Assigned by IANA > 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. o Only one identity type, ID_FQDN, MUST be implemented for Phase 1. Other identity types specified in [4] SHOULD be implemented. o Only the AES encryption [1] and HMAC-SHA1-96 hash [10] algorithms MUST be implemented as ISAKMP encryption and hash operations. As in IKE, HMAC-SHA1-96 MUST also be implemented as the default pseudo random function. Implementer's note: IKE [3] 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. 3.1 MAPSEC DOI Number Within ISAKMP, all DOI's MUST be registered with the IANA. This number is < To Be Assigned by IANA >. Arkko & Blom Expires September 20, 2004 [Page 7] Internet-Draft MAPSEC DOI March 2004 4. 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 the MAPSEC DOI MUST be able to handle the deletion of an existing SA (allowed also by IKE). 4.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. 4.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 [4]. In Phase 2, the Situation field MUST be a four (4) octet bitmask with the following value: Situation Value --------- ----- SIT_IDENTITY_ONLY 0x01 4.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 4.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. 4.3 MAPSEC Policy Requirements The policy requirements for nodes implementing the MAPSEC DOI are Arkko & Blom Expires September 20, 2004 [Page 8] Internet-Draft MAPSEC DOI March 2004 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 [7]. 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. 4.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. Section 4.6 describes ID Payload Type Values and Notify Message Types. 4.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. Protocol ID Value ----------- ----- RESERVED 0-1 PROTO_MAPSEC < To Be Assigned by IANA > 4.4.1.1 PROTO_MAPSEC The PROTO_MAPSEC type specifies the use of the MAPSEC to protect MAP messages. 4.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 Arkko & Blom Expires September 20, 2004 [Page 9] Internet-Draft MAPSEC DOI March 2004 Technical Specification [7]. 4.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 [3] for further information on attribute encoding in the MAPSEC DOI. All restrictions listed in [3] 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 RESERVED 4 - Authentication Algorithm 5 B Key Length 6 B Key Rounds 7 B RESERVED 8 - RESERVED 9 - RESERVED 10 - MAP Protection Profile 100 B MAP PP Version Indicator 101 B Class Definitions are as follows: 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. In MAPSEC DOI, the SA Life Type value MUST be seconds (1). Arkko & Blom Expires September 20, 2004 [Page 10] For a given Life Type, the value of the Life Duration attribute defines the actual length of the component lifetime -- in this case 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 attribute. Implementer's note: The semantics and values for these attributes are exactly as defined in [4], 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 [3]. Implementer's note: The semantics and values for these attributes are exactly as defined in [4]. Authentication Algorithm RESERVED 0-4 This specification only lists the reserved values. Actual Authentication Algorithm values are defined in the 3GPP Technical Specification [7]. 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 [7] 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 [4]. Arkko & Blom Expires September 20, 2004 [Page 11] Internet-Draft MAPSEC DOI March 2004 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 [4]. MAP Protection Profile The value of this attribute is a 16-bit entity as defined in [7]. 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 [7]. 4.5.1 Required Attribute Support 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 4.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 Arkko & Blom Expires September 20, 2004 [Page 12] Internet-Draft MAPSEC DOI March 2004 requirements, since only time-based lifetimes are supported. 4.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. 4.6 SA 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 [7]. The following sections describe those ISAKMP payloads whose data representations are dependent on the applicable DOI. 4.6.1 Identification Payload Content The initiator of the negotiation is identified using the 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: Arkko & Blom Expires September 20, 2004 [Page 13] Internet-Draft MAPSEC DOI March 2004 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). RESERVED (1 octet) Unused, must be zero (0). Payload Length (2 octets) Length, in octets, of the identification data, including the generic header. Identification Type (1 octet) Value describing the identity information found in the Identification Data field. 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). 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. Identification Data (variable length) Value, as indicated by the Identification Type. The legal Identification Type field values in Phase 1 are as defined in [4]. 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 12 are reserved by the IP Security DOI and other documents.) ID Type Value ------- ----- RESERVED 0-12 Arkko & Blom Expires September 20, 2004 [Page 14] Internet-Draft MAPSEC DOI March 2004 ID_PLMN_ID 100 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 [6], 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. 4.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 [5] and section 4.6.3 of [4], 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. 4.7 MAPSEC Key Exchange Requirements The MAPSEC DOI introduces no additional Key Exchange types. Arkko & Blom Expires September 20, 2004 [Page 15] Internet-Draft MAPSEC DOI March 2004 5. Key Derivation for MAPSEC MAPSEC 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 [3]. 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. Arkko & Blom Expires September 20, 2004 [Page 16] Internet-Draft MAPSEC DOI March 2004 6. Security Considerations This entire memo relates to the Internet Key Exchange protocol ([3]), which combines ISAKMP ([5]) and Oakley ([14]) 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. Arkko & Blom Expires September 20, 2004 [Page 17] Internet-Draft MAPSEC DOI March 2004 7. IANA Considerations IANA should allocate a port number for running MAPSEC DOI with ISAKMP (see Section 3). IANA should also allocate a new DOI number for MAPSEC (see Section 3.1) and a new ISAKMP Security Protocol Identifier value for PROTO_MAPSEC (see Section 4.4.1). In addition, 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 define the DOI numbers, including the DOI number for the MAPSEC 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 Transform Identifiers The MAPSEC 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 Expires September 20, 2004 [Page 18] Internet-Draft MAPSEC DOI March 2004 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 4.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. Arkko & Blom Expires September 20, 2004 [Page 19] Internet-Draft MAPSEC DOI March 2004 Normative References [1] Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003. [2] Dworkin, M., "Recommendation for Block Cipher Modes of Operation", NIST Special Publication 800-38A, December 2001. [3] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [4] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [5] Maughan, D., Schneider, M. and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [6] 3rd Generation Partnership Project, Technical Specification Group Core Network, "Mobile Application Part (MAP) Specification (Release 5)", 3GPP TS 29.002, 2002. [7] 3rd Generation Partnership Project, Technical Specification Group SA3, Security, "Network Domain Security; MAP Application Layer Security (Release 5)", 3GPP TS 33.200, 2002. [8] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [10] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. Arkko & Blom Expires September 20, 2004 [Page 20] Internet-Draft MAPSEC DOI March 2004 Informative References [11] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [12] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [13] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [14] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998. Authors' Addresses Jari Arkko Ericsson Jorvas 02420 Finland EMail: jari.arkko@ericsson.com Rolf Blom Ericsson Stockholm SE-16480 Sweden EMail: rolf.j.blom@ericsson.com Arkko & Blom Expires September 20, 2004 [Page 21] Internet-Draft MAPSEC DOI March 2004 Appendix A. 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. Arkko & Blom Expires September 20, 2004 [Page 22] Internet-Draft MAPSEC DOI March 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 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. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 assignees. Arkko & Blom Expires September 20, 2004 [Page 23] Internet-Draft MAPSEC DOI March 2004 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Arkko & Blom Expires September 20, 2004 [Page 24]