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