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]