idnits 2.17.1 draft-arkko-map-doi-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 234 has weird spacing: '...nly one ident...' == Line 346 has weird spacing: '...tifiers are ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 22, 2004) is 7339 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 722, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 743, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 754, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 757, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 760, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2409 (ref. '3') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (ref. '4') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. '5') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '10') -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. '11') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '12') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. '13') (Obsoleted by RFC 4303, RFC 4305) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Security J. Arkko 3 Internet-Draft R. Blom 4 Expires: September 20, 2004 Ericsson 5 March 22, 2004 7 The Mobile Application Part SECurity (MAPSEC) Domain of 8 Interpretation (DOI) for the Internet Security Association and Key 9 Management Protocol (ISAKMP) 10 draft-arkko-map-doi-08 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 20, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 The Mobile Application Part (MAP) protocol is a signaling protocol 42 for cellular networks. The MAP Security (MAPSEC) protocol provides a 43 secure way to transport MAP messages. To use MAPSEC, however, 44 Security Associations (SAs) are needed. This document defines how 45 such SAs can be created automatically. We use the Internet Security 46 Association and Key Management Protocol (ISAKMP) as a framework for 47 managing SAs and establishing keys. The framework can be specialized 48 to a particular task. Such a specialization is called a Domain of 49 Interpretation (DOI), and this document defines the MAPSEC DOI. This 50 specialization is very similar to the Internet Key Exchange protocol 51 and the ISAKMP specialization for IP Security, except that SAs for 52 use with non-IP protocols are being negotiated. 54 Table of Contents 56 1. Terms and Definitions . . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1 MAP and MAPSEC . . . . . . . . . . . . . . . . . . . . 4 59 2.2 Domains of Interpretation . . . . . . . . . . . . . . 4 60 2.3 Network Architecture . . . . . . . . . . . . . . . . . 5 61 3. MAPSEC DOI Phase 1 . . . . . . . . . . . . . . . . . . . . . 7 62 3.1 MAPSEC DOI Number . . . . . . . . . . . . . . . . . . 7 63 4. MAPSEC DOI Phase 2 . . . . . . . . . . . . . . . . . . . . . 8 64 4.1 Naming Scheme . . . . . . . . . . . . . . . . . . . . 8 65 4.2 MAPSEC Situation Definition . . . . . . . . . . . . . 8 66 4.2.1 SIT_IDENTITY_ONLY . . . . . . . . . . . . . . . 8 67 4.3 MAPSEC Policy Requirements . . . . . . . . . . . . . . 8 68 4.4 MAPSEC Assigned Numbers . . . . . . . . . . . . . . . 9 69 4.4.1 MAPSEC Security Protocol Identifier . . . . . . 9 70 4.4.2 MAPSEC Transform Identifiers . . . . . . . . . . 9 71 4.5 MAPSEC Security Association Attributes . . . . . . . . 10 72 4.5.1 Required Attribute Support . . . . . . . . . . . 12 73 4.5.2 Attribute Negotiation . . . . . . . . . . . . . 12 74 4.5.3 Lifetime Matching . . . . . . . . . . . . . . . 13 75 4.6 SA Payload Content . . . . . . . . . . . . . . . . . . 13 76 4.6.1 Identification Payload Content . . . . . . . . . 13 77 4.6.2 Notify Message Types . . . . . . . . . . . . . . 15 78 4.7 MAPSEC Key Exchange Requirements . . . . . . . . . . . 15 79 5. Key Derivation for MAPSEC . . . . . . . . . . . . . . . . . 16 80 6. Security Considerations . . . . . . . . . . . . . . . . . . 17 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 82 7.1 MAPSEC Situation Definition . . . . . . . . . . . . . 18 83 7.2 MAPSEC Security Protocol Identifiers . . . . . . . . . 18 84 7.3 MAPSEC Transform Identifiers . . . . . . . . . . . . . 18 85 7.4 MAPSEC Security Association Attributes . . . . . . . . 19 86 7.5 MAPSEC Identification Type . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 88 Normative References . . . . . . . . . . . . . . . . . . . . 20 89 Informative References . . . . . . . . . . . . . . . . . . . 21 90 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 22 91 Intellectual Property and Copyright Statements . . . . . . . 23 93 1. Terms and Definitions 95 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 96 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 97 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 98 described in RFC 2119 [9]. 100 2. Introduction 102 2.1 MAP and MAPSEC 104 In the Global Mobile System (GSM) and Universal Mobile 105 Telecommunication System (UMTS) networks, the MAP protocol plays a 106 central role in the signaling communications between the Network 107 Elements (NEs). User profile exchange, authentication, and mobility 108 management are performed using MAP. MAP typically runs over the 109 Signaling System number 7 (SS7) protocol stack. For a full 110 description of the MAP protocol, see [6]. 112 The mobile networks are moving to IP-based solutions. Completely 113 IP-based networks and new signaling protocols will replace MAP at 114 some point. However, MAP and SS7 signaling networks have to be 115 supported during the transition time, and beyond, due to the need to 116 retain legacy equipment in networks. 118 MAP has a role in the authentication process of GSM phones, and 119 operators are concerned about its lack of cryptographic security 120 support. For this reason a new protocol header has been developed to 121 protect MAP messages, much in the same way as the Encapsulating 122 Security Payload (ESP) protocol protects IP packets. This new 123 protocol is called MAPSEC [7]. A key management mechanism is also 124 needed for MAPSEC. This key management mechanism runs over IP. 126 2.2 Domains of Interpretation 128 The Internet Security Association and Key Management Protocol 129 (ISAKMP) provides a common framework for protocols that manage 130 Security Associations (SAs) and establish keys. This framework may 131 be specialized to different tasks, with different requirements and 132 security properties. Each such specialization results in a new 133 task-specific protocol. ISAKMP provides a common message format for 134 these protocols. 136 A specialization of ISAKMP is called a Domain of Interpretation 137 (DOI). A DOI defines the interpretation of task-specific parts in 138 ISAKMP messages. These parts include the fields which are used to 139 inform the peer about the supported cryptographic algorithms and 140 protocols, and the fields which are used to carry the identities of 141 the parties. As ISAKMP is used in different tasks, the required 142 algorithms and other parameters may be different. 144 For instance, the IP Security DOI [4] describes the use of ISAKMP in 145 the context of IP Security protocols (AH, ESP) and IP Compression. 146 The Internet Key Exchange (IKE) protocol uses the IP Security DOI. 147 The IKE protocol, and the parameters of the DOI are divided in two 148 phases: In Phase 1, an authentication is performed and protection for 149 ISAKMP itself is set up. In Phase 2, actual AH and ESP SAs are 150 negotiated. 152 This document defines the MAPSEC DOI for ISAKMP. This DOI can be 153 used to negotiate MAPSEC SAs. Phase 1 related issues for the MAPSEC 154 DOI are described in Section 3. Phase 2 related issues are described 155 in Section 4. In addition, 3GPP Technical Specifications [7] specify 156 the actual MAPSEC authentication and encryption algorithms and the so 157 called protection profiles. Protection Profiles indicate the 158 protection requirements for each MAP message type. [7] defines also 159 the values that are used in the MAPSEC DOI to refer to these 160 algorithms and profiles. This ensures that the MAPSEC DOI document 161 does not have to be modified upon the development of a new 162 authentication algorithm, for instance. 164 This new DOI is very similar to the IP Security DOI and IKE. The 165 only technical differences are with respect to the Phase 2, otherwise 166 a subset of the IP Security DOI and IKE is used. MAPSEC DOI is 167 separated from IKE as a new DOI rather than an extension of the 168 current one in order to allow the two protocols to have different 169 port numbers, name spaces, and change control in the future. 171 If IKE is developed further or replaced by new protocols, it is 172 possible to update the MAPSEC DOI to use a new protocol. Such an 173 update would involve extending the new protocol to allow other 174 protocols than AH and ESP, and allowing certain new algorithm 175 identifiers and other parameters. 177 2.3 Network Architecture 179 The MAP Security (MAPSEC) protocol and its key management part 180 provide authentication, confidentiality, integrity, and replay 181 protection services to the MAP messages it transports. 183 The purpose of the MAPSEC header in the protocol is to provide enough 184 information to determine the MAPSEC SA and Protection Profiles used 185 in securing the MAP operation that follows the header. 187 MAPSEC DOI and IKE are used to set up SAs for nodes implementing 188 MAPSEC. While the MAP protocol usually runs over SS7, the MAPSEC DOI 189 and IKE are always run over IP. Therefore, it is assumed that nodes 190 or networks implementing MAPSEC always have IP connectivity in 191 addition to SS7 connectivity. Figure 1 below depicts the situation. 193 _---------MAPSEC key management over IP-------_ 194 / \ 195 | | 196 +-----------+ +-----------+ 197 | | | | 198 | Node or | | Node or | 199 | Network 1 |---------MAPSEC over SS7---------| Network 2 | 200 | | | | 201 | | | | 202 +-----------+ +-----------+ 204 Figure 1: Network architecture for MAPSEC 206 The network architectures where the MAPSEC DOI can be run includes, 207 but are not limited to, the one defined by 3GPP [7]. In the 3GPP 208 architecture the MAPSEC is typically run between two different 209 network operators, and the same SAs are shared by a number of NEs. 211 As in IKE, the MAPSEC DOI always establishes two simplex SAs, one for 212 the incoming and another one for the outgoing direction. These SAs 213 differ only with respect to the keys, SPIs, and peer identities but 214 all other parameters including the algorithms MUST have the same 215 values. 217 3. MAPSEC DOI Phase 1 219 For Phase 1, all IP Security DOI definitions [4] and IKE procedures 220 [5, 3] MUST be used unchanged in the MAPSEC DOI, including the way 221 that peers are authenticated. However, with the MAPSEC DOI the 222 following exceptions to the full requirements will apply: 224 o All MAPSEC DOI communications SHOULD run on port < To Be Assigned 225 by IANA > instead of the standard IKE port 500. This applies to 226 both Phase 1 and 2. Additionally, MAPSEC DOI implementations MUST 227 send the value zero in the port field of the identity payload 228 during Phase 1 (standard IKE allows either 0 or 500). 230 o Support for Perfect Forward Secrecy (PFS) is NOT REQUIRED. An 231 implementation that receives a Phase 2 negotiation request with 232 PFS on MAY decline the negotiation. 234 o Only one identity type, ID_FQDN, MUST be implemented for 235 Phase 1. Other identity types specified in [4] SHOULD be 236 implemented. 238 o Only the AES encryption [1] and HMAC-SHA1-96 hash [10] algorithms 239 MUST be implemented as ISAKMP encryption and hash operations. As 240 in IKE, HMAC-SHA1-96 MUST also be implemented as the default 241 pseudo random function. 243 Implementer's note: IKE [3] specifies that all implementations MUST 244 support authentication through pre-shared secrets and SHOULD support 245 public key based authentication. All implementations also MUST 246 support Main Mode. 248 3.1 MAPSEC DOI Number 250 Within ISAKMP, all DOI's MUST be registered with the IANA. This 251 number is < To Be Assigned by IANA >. 253 4. MAPSEC DOI Phase 2 255 IKE procedures regarding Phase 2 are used unchanged, with the 256 following exceptions: 258 o Identity types used in Phase 2 are different. 260 o SA payloads are different. 262 o There are no MAPSEC-specific Phase 2 notifications. 264 Note also that all implementations of the MAPSEC DOI MUST be able to 265 handle the deletion of an existing SA (allowed also by IKE). 267 4.1 Naming Scheme 269 Within the MAPSEC DOI, all well-known identifiers MUST be registered 270 as explained in Section 7. 272 All multi-octet binary values are stored in network byte order. 274 4.2 MAPSEC Situation Definition 276 Within ISAKMP, the Situation field provides information that can be 277 used by the responder to make a policy determination about how to 278 process the incoming negotiation request. For the MAPSEC DOI, the 279 Situation field in Phase 1 is handled as specified by the IP Security 280 DOI [4]. In Phase 2, the Situation field MUST be a four (4) octet 281 bitmask with the following value: 283 Situation Value 284 --------- ----- 285 SIT_IDENTITY_ONLY 0x01 287 4.2.1 SIT_IDENTITY_ONLY 289 The SIT_IDENTITY_ONLY type specifies that the SA will be identified 290 by source identity information present in an associated 291 Identification Payload. See Section 4.6.1 for a complete description 292 of the various Identification types. All MAPSEC DOI implementations 293 MUST support SIT_IDENTITY_ONLY by including two Identification 294 Payloads in the Phase 2 exchange, and MUST abort any negotiation that 295 fails to do so. 297 4.3 MAPSEC Policy Requirements 299 The policy requirements for nodes implementing the MAPSEC DOI are 300 beyond the scope of this document. However, it is required that 301 systems are able to specify their policies with respect to the MAP 302 traffic in terms of Protection Profiles as defined in [7]. These 303 Protection Profiles indicate the need for a particular kind of 304 protection based on the type of the MAP message. For the purposes of 305 this document a Protection Profile is a 16 bit number that is agreed 306 during the SA negotiation. 308 4.4 MAPSEC Assigned Numbers 310 The following sections list the Assigned Numbers for the MAPSEC DOI. 311 Sections 5.4.1 to 5.5 describe Protocol Identifiers, MAPSEC Transform 312 Identifiers and Security Association Attribute Type Values. Section 313 4.6 describes ID Payload Type Values and Notify Message Types. 315 4.4.1 MAPSEC Security Protocol Identifier 317 The ISAKMP proposal syntax was specifically designed to allow for the 318 simultaneous negotiation of multiple Phase 2 security protocol suites 319 within a single negotiation. As a result, the protocol suites listed 320 below form the set of protocols that can be negotiated at the same 321 time. The combination of protocol suites that may be negotiated 322 together is a host policy decision. 324 The following table lists the values for the Security Protocol 325 Identifiers referenced in an ISAKMP Proposal Payload for the MAPSEC 326 DOI. 328 Protocol ID Value 329 ----------- ----- 330 RESERVED 0-1 331 PROTO_MAPSEC < To Be Assigned by IANA > 333 4.4.1.1 PROTO_MAPSEC 335 The PROTO_MAPSEC type specifies the use of the MAPSEC to protect MAP 336 messages. 338 4.4.2 MAPSEC Transform Identifiers 340 The following table lists the reserved MAPSEC Transform Identifiers. 342 Transform ID Value 343 ------------ ----- 344 RESERVED 0-1 346 Actual MAP Transform Identifiers are defined in the 3GPP 347 Technical Specification [7]. 349 4.5 MAPSEC Security Association Attributes 351 The following SA attribute definitions are used in Phase 2 of an IKE 352 negotiation. Attribute types can be either Basic (B) or 353 Variable-Length (V). Encoding of these attributes is defined in the 354 base ISAKMP specification. 356 Attributes defined as Basic MUST NOT be encoded as Variable-Length. 357 Variable-Length attributes MAY be encoded as Basic attributes if 358 their value can fit into two octets. See [3] for further information 359 on attribute encoding in the MAPSEC DOI. All restrictions listed in 360 [3] also apply to the MAPSEC DOI. 362 Implementer's note: The attributes described here behave exactly as 363 the corresponding ones in the IP Security DOI, unless otherwise 364 explicitly specified. For the purposes of reusing IP Security DOI 365 code, the parameters not used by MAPSEC DOI are defined as class 366 RESERVED (values 4, 8, and 9). 368 Attribute Types 370 class value type 371 ------------------------------------------------- 372 SA Life Type 1 B 373 SA Life Duration 2 V 374 Group Description 3 B 375 RESERVED 4 - 376 Authentication Algorithm 5 B 377 Key Length 6 B 378 Key Rounds 7 B 379 RESERVED 8 - 380 RESERVED 9 - 381 RESERVED 10 - 382 MAP Protection Profile 100 B 383 MAP PP Version Indicator 101 B 385 Class Definitions are as follows: 387 SA Life Type 389 SA Duration 391 Specifies the time-to-live for the SA. When the SA expires, the 392 SA MUST be renegotiated. MAPSEC messages using the expired SA 393 MUST no longer be either sent or accepted as input. In MAPSEC 394 DOI, the SA Life Type value MUST be seconds (1). 396 For a given Life Type, the value of the Life Duration attribute 397 defines the actual length of the component lifetime -- in this 398 case in seconds. If unspecified, the default value MUST be 399 assumed to be 28800 seconds (8 hours). 401 The SA Life Duration attribute MUST always follow the SA Life Type 402 attribute. 404 Implementer's note: The semantics and values for these attributes 405 are exactly as defined in [4], except that kilobyte lifetimes are 406 not supported. 408 Group Description 410 Specifies the Oakley Group to be used in a PFS QM negotiation. 411 For a list of supported values, see Appendix A of [3]. 413 Implementer's note: The semantics and values for these attributes 414 are exactly as defined in [4]. 416 Authentication Algorithm 418 RESERVED 0-4 420 This specification only lists the reserved values. Actual 421 Authentication Algorithm values are defined in the 3GPP Technical 422 Specification [7]. 424 There is no default value for Authentication Algorithm. It MUST 425 be always sent. 427 Implementer's note: The first five values are reserved by the IP 428 Security DOI. 430 Key Length 432 RESERVED 0 434 There is no default value for Key Length. This attribute MUST be 435 sent for transforms that use ciphers with variable key lengths. 436 For fixed length ciphers, the Key Length attribute MUST NOT be 437 sent. The definition of MAPSEC transforms in the 3GPP Technical 438 Specifications such as [7] MUST specify if the use of Key Length 439 is necessary and what the legal values are. 441 Implementer's note: The semantics and values for these attributes 442 are exactly as defined in [4]. 444 Key Rounds 446 RESERVED 0 448 There is no default value for Key Rounds, as it must be specified 449 for transforms using ciphers with varying numbers of rounds. 451 Implementer's note: The semantics and values for these attributes 452 are exactly as defined in [4]. 454 MAP Protection Profile 456 The value of this attribute is a 16-bit entity as defined in [7]. 458 MAP PP Version Indicator 460 The Protection Profile Version Indicator allows different versions 461 of protection profiles to be used. The value of this attribute is 462 a 16-bit entity as defined in [7]. 464 4.5.1 Required Attribute Support 466 To ensure basic interoperability, all implementations MUST be able to 467 negotiate all of the following attributes: 469 SA Life Type 470 SA Duration 471 Authentication Algorithm 472 Key Length 473 MAP Protection Profile 474 MAP PP Version Indicator 476 4.5.2 Attribute Negotiation 478 If an implementation receives a defined MAPSEC DOI attribute (or 479 attribute value) which it does not support, an ATTRIBUTES-NOT- 480 SUPPORTED Notification Payload SHOULD be returned and the negotiation 481 MUST be aborted, unless the attribute value is in the reserved range. 483 If an implementation receives an attribute value in the reserved 484 range, an implementation MAY choose to continue based on local 485 policy. 487 Implementer's note: This follows exactly the IP Security DOI. 488 However, there are no special lifetime attribute parsing 489 requirements, since only time-based lifetimes are supported. 491 4.5.3 Lifetime Matching 493 Offered and locally acceptable SA lifetimes must match exactly under 494 MAPSEC in order for the responder to select an SA. 496 Implementer's note: This is simplified from the IP Security DOI which 497 required notifications. In the MAPSEC DOI lifetime notifications are 498 not defined and hence not used. 500 4.6 SA Payload Content 502 The SA Payloads that the Initiator and the Responder exchange control 503 the SAs that actually get installed. The attributes discussed above 504 are a part of the SA Payloads. For a definition of a MAPSEC SA, see 505 [7]. 507 The following sections describe those ISAKMP payloads whose data 508 representations are dependent on the applicable DOI. 510 4.6.1 Identification Payload Content 512 The initiator of the negotiation is identified using the 513 Identification Payload. The responder SHOULD use the initiator's 514 identity to determine the correct security policy for creating SAs. 516 During Phase 1, the ID port and protocol fields MUST be set to zero 517 or to the UDP port that the MAPSEC DOI is running on. If an 518 implementation receives any other values, this MUST be treated as an 519 error and the negotiation MUST be aborted. 521 The following diagram illustrates the content of the Identification 522 Payload. 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 ! Next Payload ! RESERVED ! Payload Length ! 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 ! ID Type ! Protocol ID ! Port ! 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 ~ Identification Data ~ 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Figure 2: Identification Payload Format 535 The Identification Payload fields are defined as follows: 537 Next Payload (1 octet) 539 Identifier for the type of the next payload in the message. If 540 the current payload is the last in the message, this field will be 541 zero (0). 543 RESERVED (1 octet) 545 Unused, must be zero (0). 547 Payload Length (2 octets) 549 Length, in octets, of the identification data, including the 550 generic header. 552 Identification Type (1 octet) 554 Value describing the identity information found in the 555 Identification Data field. 557 Protocol ID (1 octet) 559 Value specifying an associated Transport Layer Protocol ID (e.g. 560 UDP/TCP). Value zero means that the Protocol ID field should be 561 ignored. In the MAPSEC DOI Phase 2, the Protocol field MUST 562 always be zero (0). 564 Port (2 octets) 566 Value specifying an associated port. A value of zero means that 567 the Port field should be ignored. In the MAPSEC DOI, value of 568 zero MUST always be used in Phase 2. Unlike in IP traffic 569 protected by IP Security, the concept of a port is not used in 570 MAP. 572 Identification Data (variable length) 574 Value, as indicated by the Identification Type. 576 The legal Identification Type field values in Phase 1 are as defined 577 in [4]. Phase 2 identities MUST conform to the following table. The 578 table lists the assigned values for the Identification Type field 579 found in the Identification Payload. (Values from 0 to 12 are 580 reserved by the IP Security DOI and other documents.) 582 ID Type Value 583 ------- ----- 584 RESERVED 0-12 585 ID_PLMN_ID 100 587 In MAPSEC DOI, the ID_PLMN_ID type specifies PLMN ID of the Initiator 588 or the Responder. The PLMN ID MUST be represented as defined in 589 section 17.7.8 of [6], i.e. as a three octet data item with the 590 Mobile Country Code (MCC) followed by the Mobile Network Code (MNC). 591 The size of the PLMN ID MUST correspond to the size in the ID payload 592 header. 594 4.6.2 Notify Message Types 596 There are no DOI-specific Notify Message types for the MAPSEC DOI in 597 Phase 2. 599 Note however that Phase 1 uses the standard ISAKMP and IP Security 600 DOI notifications that are defined in section 3.14.1 of [5] and 601 section 4.6.3 of [4], respectively. Even Phase 2 of the MAPSEC DOI 602 uses standard ISAKMP notifications. 604 Implementer's note: The reason why MAPSEC DOI does not need the same 605 Phase 2 DOI-specific notifications is the following. MAPSEC does not 606 allow turning replay protection on or off, which makes the use of 607 REPLAY-STATUS unnecessary. Responder lifetimes are required to be 608 exactly the same as the initiator lifetimes, which makes the use of 609 RESPONDER-LIFETIME unnecessary. INITIAL-CONTACT notification on the 610 other hand is used exclusively in Phase 1, and is therefore 611 applicable also for MAPSEC DOI in Phase 1. 613 4.7 MAPSEC Key Exchange Requirements 615 The MAPSEC DOI introduces no additional Key Exchange types. 617 5. Key Derivation for MAPSEC 619 MAPSEC requires two sets of keys, one for each direction, just as in 620 the case of IP Security SAs. Separate authentication and encryption 621 keys are also needed for each direction. For one direction, these 622 two keys are taken from the keying material in following order: first 623 the authentication key, and then the encryption key. 625 The keys are derived with the procedure described in Section 5.5 of 626 [3]. 628 Implementer's note: The same procedure is used in order to simplify 629 specification and implementation. Note also that one of the 630 parameters needed for the derivation process is constant, i.e. the 631 protocol is always PROTO_MAPSEC. 633 6. Security Considerations 635 This entire memo relates to the Internet Key Exchange protocol ([3]), 636 which combines ISAKMP ([5]) and Oakley ([14]) to provide the 637 derivation of cryptographic keying material in a secure and 638 authenticated manner. Specific discussion of the various security 639 protocols and transforms identified in this document can be found in 640 the associated base documents and in the cipher references. 642 7. IANA Considerations 644 IANA should allocate a port number for running MAPSEC DOI with ISAKMP 645 (see Section 3). IANA should also allocate a new DOI number for 646 MAPSEC (see Section 3.1) and a new ISAKMP Security Protocol 647 Identifier value for PROTO_MAPSEC (see Section 4.4.1). 649 In addition, this document contains many parameters to be maintained 650 by the the standardization bodies. In the case of the MAPSEC DOI, 651 3GPP will assign many of the parameters normally maintained by IANA. 652 This section explains how 3GPP will assign new values for different 653 MAPSEC DOI related parameters. All values not explicitly defined in 654 previous sections will be assigned by 3GPP. IANA will define the DOI 655 numbers, including the DOI number for the MAPSEC DOI. 657 7.1 MAPSEC Situation Definition 659 The Situation Definition is a 32-bit bitmask which represents the 660 environment under which the MAPSEC SA proposal and negotiation is 661 carried out. Requests for new Situation Definition values must be 662 accompanied by a 3GPP Technical Specification which describes the new 663 Situation. 665 The upper two bits are reserved for private use between cooperating 666 systems. 668 7.2 MAPSEC Security Protocol Identifiers 670 The Security Protocol Identifier is an 8-bit value which identifies a 671 security protocol suite being negotiated. Requests for new security 672 protocol identifiers must be accompanied by a 3GPP Technical 673 Specification which describes the security protocol. 675 The values 249-255 are reserved for private use between cooperating 676 systems. 678 7.3 MAPSEC Transform Identifiers 680 The MAPSEC Transform Identifier is an 8-bit value which identifies 681 the algorithm to be used to protect for MAP messages. Requests for 682 new Transform Identifiers must be accompanied by a 3GPP Technical 683 Specification describing the use of the algorithm within the MAPSEC 684 DOI framework. 686 The values 249-255 are reserved for private use between cooperating 687 systems. 689 7.4 MAPSEC Security Association Attributes 691 The MAPSEC Security Association Attribute consists of a 16-bit type 692 definition and its associated value. MAPSEC SA attributes are used 693 to pass miscellaneous values between ISAKMP peers. Requests for new 694 MAPSEC SA attributes must be accompanied by a 3GPP Technical 695 Specification describing the attribute semantics, its type encoding 696 (Basic/Variable-Length) and its legal values. Section 4.5 of this 697 document provides an example of such a description. 699 The values 32001-32767 are reserved for private use between 700 cooperating systems. 702 Requests for new values for existing attributes must be accompanied 703 also by a 3GPP Technical Specification. Such specifications describe 704 the semantics of the new values. 706 7.5 MAPSEC Identification Type 708 The MAPSEC Identification Type is an 8-bit value which is used as a 709 discriminant for the interpretation of the variable-length 710 Identification Payload. Requests for new Identification Types must 711 be accompanied by a 3GPP Technical Specification which describes how 712 to use the identification type. 714 The values 249-255 are reserved for private use between cooperating 715 systems. 717 Normative References 719 [1] Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher 720 Algorithm and Its Use with IPsec", RFC 3602, September 2003. 722 [2] Dworkin, M., "Recommendation for Block Cipher Modes of 723 Operation", NIST Special Publication 800-38A, December 2001. 725 [3] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 726 RFC 2409, November 1998. 728 [4] Piper, D., "The Internet IP Security Domain of Interpretation 729 for ISAKMP", RFC 2407, November 1998. 731 [5] Maughan, D., Schneider, M. and M. Schertler, "Internet Security 732 Association and Key Management Protocol (ISAKMP)", RFC 2408, 733 November 1998. 735 [6] 3rd Generation Partnership Project, Technical Specification 736 Group Core Network, "Mobile Application Part (MAP) 737 Specification (Release 5)", 3GPP TS 29.002, 2002. 739 [7] 3rd Generation Partnership Project, Technical Specification 740 Group SA3, Security, "Network Domain Security; MAP Application 741 Layer Security (Release 5)", 3GPP TS 33.200, 2002. 743 [8] Bradner, S., "The Internet Standards Process -- Revision 3", 744 BCP 9, RFC 2026, October 1996. 746 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement 747 Levels", BCP 14, RFC 2119, March 1997. 749 [10] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 750 for Message Authentication", RFC 2104, February 1997. 752 Informative References 754 [11] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 755 November 1998. 757 [12] Kent, S. and R. Atkinson, "Security Architecture for the 758 Internet Protocol", RFC 2401, November 1998. 760 [13] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 761 (ESP)", RFC 2406, November 1998. 763 [14] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, 764 November 1998. 766 Authors' Addresses 768 Jari Arkko 769 Ericsson 771 Jorvas 02420 772 Finland 774 EMail: jari.arkko@ericsson.com 776 Rolf Blom 777 Ericsson 779 Stockholm SE-16480 780 Sweden 782 EMail: rolf.j.blom@ericsson.com 784 Appendix A. Acknowledgments 786 This document is derived from the work done by the SA3 group of 3GPP. 787 The authors wish to thank in particular David Castellanos- Zamora, 788 Krister Boman, Anders Liljekvist, Eeva Munter and others at Ericsson, 789 and Tatu Ylonen and others at SSH Communications Security Corp, Marc 790 Blommaert, Dirk Kroeselberg, and Ulrich Wiehe at Siemens, and Olivier 791 Paridaens at Alcatel. 793 Intellectual Property Statement 795 The IETF takes no position regarding the validity or scope of any 796 intellectual property or other rights that might be claimed to 797 pertain to the implementation or use of the technology described in 798 this document or the extent to which any license under such rights 799 might or might not be available; neither does it represent that it 800 has made any effort to identify any such rights. Information on the 801 IETF's procedures with respect to rights in standards-track and 802 standards-related documentation can be found in BCP-11. Copies of 803 claims of rights made available for publication and any assurances of 804 licenses to be made available, or the result of an attempt made to 805 obtain a general license or permission for the use of such 806 proprietary rights by implementors or users of this specification can 807 be obtained from the IETF Secretariat. 809 The IETF invites any interested party to bring to its attention any 810 copyrights, patents or patent applications, or other proprietary 811 rights which may cover technology that may be required to practice 812 this standard. Please address the information to the IETF Executive 813 Director. 815 The IETF has been notified of intellectual property rights claimed in 816 regard to some or all of the specification contained in this 817 document. For more information consult the online list of claimed 818 rights. 820 Full Copyright Statement 822 Copyright (C) The Internet Society (2004). All Rights Reserved. 824 This document and translations of it may be copied and furnished to 825 others, and derivative works that comment on or otherwise explain it 826 or assist in its implementation may be prepared, copied, published 827 and distributed, in whole or in part, without restriction of any 828 kind, provided that the above copyright notice and this paragraph are 829 included on all such copies and derivative works. However, this 830 document itself may not be modified in any way, such as by removing 831 the copyright notice or references to the Internet Society or other 832 Internet organizations, except as needed for the purpose of 833 developing Internet standards in which case the procedures for 834 copyrights defined in the Internet Standards process must be 835 followed, or as required to translate it into languages other than 836 English. 838 The limited permissions granted above are perpetual and will not be 839 revoked by the Internet Society or its successors or assignees. 841 This document and the information contained herein is provided on an 842 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 843 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 844 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 845 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 846 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 848 Acknowledgement 850 Funding for the RFC Editor function is currently provided by the 851 Internet Society.