INTERNET DRAFT G. Gross
Multicast Security working group IdentAware Security
Expires: January 4 2004 July 4 2004
The Group Security Association Key Management Protocol
Application to the IP Security Architecture
<draft-gross-msec-gsakmp-ipsec-arch-00.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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.
Copyright (C) The Internet Society (2004), All Rights Reserved
Abstract
The Group Security Association Key Management Protocol (GSAKMP)is a
distributed secure multicast framework and key management protocol.
This specification defines the GSAKMP profile for the IP security
architecture version 2 and extends the base GSAKMP protocol with the
Security Association Management (SAM) message. The GSAKMP IPsec
policy token explicitly authorizes which group members may exercise
the speaker privilege. When an authorized group speaker endpoint
multicasts a SAM message to a GSAKMP group, the SAM message
configures that group's Security Policy Databases and Security
Association Databases in compliance to a template within the GSAKMP
IPsec policy token. In addition, this specification profiles the
three supporting components: RFC2401-bis compliant IP security
subsystem, Negative-acknowledgement Oriented Reliable Multicast
(NORM) protocol handler, and the X.509 Public Key Infrastructure.
Gross Expires January, 2005 page 1
GSAKMP Application to the IP Security Architecture July, 2004
1 GSAKMP IP Security Architecture Overview...............4
1.1.......................................GSAKMP Profile 5
1.2........................IP Security Subsystem Profile 7
1.3............GSAKMP IP Security Policy Token Extension 7
1.4....NACK Oriented Reliable Multicast Protocol Profile 7
1.5...................Interactions with NAT and Mobility 8
1.6........Group Speaker Security Association Management 8
1.7....................Public Key Infrastructure Profile 8
2 Terminology and Definitions of Terms...................9
3 GSAKMP IPsec Identifier and Addressing Architecture...11
3.1...........................GSAKMP Group Node Identity 11
3.1.1 Node Identity as a Unicast IP-v6 Address 12
3.1.2 Node Identity Public Key Certificate 13
3.1.3 Secure Identity to Address Mapping Database 13
3.2........................GSAKMP IPsec Group Identifier 14
3.3.....GSAKMP IPsec Transport Layer Endpoint Identifier 15
3.3.1 Transport Layer Endpoint Identifier Definition 15
3.3.2 Application Endpoint Signature Certificate 16
3.3.3 Transport Endpoint Binding Attribute Certificate 17
3.4.....Receiver Multicast Packet Distributor Identifier 18
3.5......GSAKMP Group Any Source Multicast IP-v6 Address 19
3.6.GSAKMP Group Source-Specific Multicast IP-v6 Address 20
3.7.................GSAKMP Group Multicast IP-v4 Address 20
4 GSAKMP IP Security Implementation Profile.............20
4.1..............................GSAKMP Security Suite 2 21
4.2...............Group Re-Keying Algorithm and Protocol 21
4.3..............GC/KS Re-Key Group Security Association 22
4.4.........................................Verbose Mode 22
4.5......Identification and Signature's Identifier Types 23
4.6................Lack Of Acknowledgement (LOA) Message 23
4.7.....Registration Exchange Transport Layer Parameters 23
4.8......GSAKMP Registration Protocol Exchange Extension 23
4.9De-Registration Security Association Protocol Exchange 27
4.10..................GSAKMP Autonomous Distributed Mode 27
4.11....................Group Owner Management Interface 28
4.12..............GSAKMP Node Local Management Interface 28
4.13.Coordinating Security Policies Between Group Owners 29
5 GSAKMP IP Security Subsystem Profile..................29
5.1.....GSAKMP Requirements on the IP Security Subsystem 30
5.2....Authentication Header Group Security Associations 31
5.3..........Secure Multicast Application Service Models 32
5.3.1 Unidirectional Multicast Applications 32
5.3.2 Bi-directional Reliable Multicast Applications 32
5.3.3 Any-To-Any Multicast Applications 33
5.4....Co-Existence of Multiple Key Management Protocols 33
Gross Expires January, 2004 page 2
GSAKMP Application to the IP Security Architecture July, 2004
5.5...................................ESP GSA Properties 34
5.6...............Concurrent GSA Life Spans and Rollover 35
5.7....Multiple Group Speakers and Source Authentication 37
5.8...............GSAKMP IPsec Interactions with the PAD 38
5.9.....Security Policy Database Symbolic Name Selectors 38
5.10.............Tunnel Mode Group Security Associations 40
5.11..........Multicast Packet Distributor Policy Action 40
5.11.1 Basic and Composite GSAKMP Groups 41
5.11.2 Transmitter Multicast Packet Distributor 42
5.11.3 Receiver Multicast Packet Distributor 43
5.12............................UDP Encapsulated ESP GSA 43
6 GSAKMP Interactions with NAT and Mobility.............43
6.1SPD Losses Synchronization with Internet Layer's State 44
6.1.1Mobile Multicast Care-Of Address Route Optimization 44
6.1.2 NAT Translation Mappings Are Not Predictable 44
6.2..........Secondary Problems Created by NAT Traversal 45
6.2.1 SSM Routing Dependency on Source IP Address 45
6.2.2 ESP Cloaks Its Payloads from NAT Gateway 45
6.2.3 UDP Checksum Dependency on Source IP Address 46
6.2.4 Can Not Use AH with NAT Gateway 46
6.3...Avoidance of NAT Using an IP-v6 Over IP-v4 Network 46
6.4............GSAKMP Multi-Realm IP-v4 NAT Architecture 48
6.4.1 GSAKMP IP-v4 NAT Architectural Assumptions 48
6.4.2 Representative GSAKMP Multi-Realm Configuration 50
6.4.3 Registration Security Association NAT Traversal 51
6.4.4 GSAKMP Re-key GSA NAT Traversal 52
6.4.5 Application GSA NAT Traversal 52
7 Security Association Management Message...............54
7.1GSAKMP Security Association Management Message Syntax 55
7.2.............................SAM Message Verification 57
7.3.SAM Message Processing After Successful Verification 58
7.4........Identity to Transient Address Mapping Payload 59
7.5...........Security Association Configuration Payload 63
7.6........................Security Association Template 67
7.7..........GC/KS Co-located at the Transit NAT Gateway 68
7.8....................SAM Notification Payload Handling 68
8 NACK-Oriented Reliable Multicast Protocol Profile.....68
8.1.............GSAKMP/NORM Subsystem Mandatory Features 69
8.2..................Forward Error Correction Algorithms 70
8.3...................Group-wide Default Path MTU Length 70
9 GSAKMP IP Security Public Key Infrastructure Profile..71
9.1.Identification and Signature Payload Signer ID Types 71
9.2...........Application Endpoint Signature Certificate 72
9.2.1 Subject Field Distinguished Name 72
9.2.2 SubjectAltName Extension 72
Gross Expires January, 2004 page 3
GSAKMP Application to the IP Security Architecture July, 2004
9.2.3 Issuer Field 72
9.2.4 Key Usage and Extended Key Usage Fields 72
9.3.....................GSAKMP Certificate Payload Types 73
9.4......Node Identity End-Entity Public Key Certificate 73
9.4.1 Subject and SubjectAltName Extension 73
9.4.2 Unique Identifiers 74
9.4.3 Key Usage and Extended Key Usage Extensions 74
9.4.4 Certificate Policies Extension 74
9.4.5 Subject Key Identifier Extension 74
9.4.6 Authority Key Identifier Extension 74
9.4.7 Basic Constraints Extension 74
9.5...Group Trust Anchor Public Key Certificate Key-ring 74
9.6.....Transport Endpoint Binding Attribute Certificate 75
9.6.1 IssuerName Field 75
9.6.2 Holder Field 75
9.6.3 TEBAC Issuer Signature Algorithm 75
9.6.4 Validity Period and TEBAC Revocation Strategy 75
9.6.5 Attribute Certificate Targeting Extension 76
9.6.6 Group Attribute Type 76
9.6.7 Access Identity Attribute Type 76
9.6.8 Optional Attribute Types 78
10.................................Security Considerations 78
11.....................................IANA Considerations 78
11.1...................GSAKMP IPsec Specific Allocations 78
11.2.............................SAM Message Nonce Types 79
11.3GSAKMP IP Security Specific Notify Payload Error Codes 79
12........................................Acknowledgements 80
13....................................Normative References 80
14..................................Informative References 80
15..............................Author Contact Information 82
16.........................Intellectual Property Statement 82
17.....................................Copyright Statement 82
18....................................Disclaimer Statement 83
19..............................................APPENDIX A 83
1 GSAKMP IP Security Architecture Overview
The Group Security Association Key Management Protocol (GSAKMP) base
specification [GSAKMP] provides a distributed, application
independent secure multicast framework and key management protocol.
Figure 1 illustrates the GSAKMP mapping to the IP security
architecture.
The primary goal of the GSAKMP IP Security application is to assure
inter-operable implementations across all facets of the IP security
Gross Expires January, 2004 page 4
GSAKMP Application to the IP Security Architecture July, 2004
architecture shown in figure 1. The GSAKMP IP Security application
builds on the revised IP multicast security [RFC2401-bis]
capabilities that were not available in the predecessor IP security
architecture [RFC2401]. Implementations that claim compliance to
this GSAKMP IPsec application standard MUST support all of this
document's mandatory to implement GSAKMP IPsec application-specific
features, GSAKMP protocol extensions, and profiled parameters for
the supporting architectural components. The GSAKMP IPsec
application specifications divide into seven categories, as
described in the ensuing sections.
Although figure 1 only shows a monolithic GSAKMP component, all
GSAKMP IPsec implementations MUST be capable of operating in Group
Member (GM) role, or Subordinate Group Control/Key Server (S-GC/KS)
role. Local policy sets the role authorization for a Node on a per
group basis. A Node MAY also be capable of acting in the Primary
Group Control/Key Server (P-GC/KS) role. Unless qualified to the
contrary, the term "GC/KS" refers interchangeably to either a
Subordinate GC/KS or a Primary GC/KS. The Group Owner component
interacts with the Primary GC/KS through a private interface or
protocol that is outside the scope of this standard.
1.1 GSAKMP Profile
The GSAKMP base specification offers numerous options, and it defers
the definition of application specific semantics to other documents.
Section 4 prescribes the mandatory set of must implement options
when applying GSAKMP to the IP security architecture. Wherever there
are application-specific omissions or ambiguities in the GSAKMP base
specification, this specification interprets what must be done to
assure protocol interoperability between independently produced
GSAKMP IPsec implementations. This includes the GSAKMP IPsec
management interface configuration capabilities, such that any two
implementations can be administered to inter-operate.
Gross Expires January, 2004 page 5
GSAKMP Application to the IP Security Architecture July, 2004
+-----------+ +----+---------------------------------+--------+
| multicast <====>SIAM| Group Security Association Key | Group |
|application|(C2)| | Mgmnt. Protocol (GSAKMP) IPsec | Owner |
+-/\-----/\-+ +----+-/\------------/\------A----A----+-A------+
|| || || || | | |
|| || || || | +------|
(D0) (D1) (D2) (D3) (C0) (C1)
|| || || || | |
|| || || || | +-------V------+
|| || || || | | Public Key |
|| || || || | |Infrastructure|
|| || || || | | subsystem |
|| || || || | +--------------+
|| || || || |
|| +--\/-------------\/---+ || |
|| |Negative-ack Oriented | || |
|| | Reliable Multicast | || |
|| |(NORM) protocol subset| || |
|| +---------/\-----------+ || |
|| || || |
|| || || |
+-\/------------\/--------------------\/-+ |
| U s e r D a t a g r a m | |
| P r o t o c o l ( U D P ) | |
+---------------/\-----------------------+ |
|| |
|| |
+---------------\/----------------------------V---+
| I P S e c u r i t y S u b s y s t e m |
| +--------------------------------+ |
| | Security Policy Database (SPD) | |
| +--------------------------------+ |
| | Security Assoc. Database (SAD) | |
| +--------------------------------+ |
| | Peer Authoriztn. Database (PAD)| |
| +--------------------------------+ |
+----------------------/\-------------------------+
||
||
+----------------------\/-------------------------+
| I n t e r n e t P r o t o c o l ( I P ) |
| |
| V 4 o r V 6 L a y e r |
+-------------------------------------------------+
Figure 1 GSAKMP IP security architectural model
Gross Expires January, 2004 page 6
GSAKMP Application to the IP Security Architecture July, 2004
1.2 IP Security Subsystem Profile
Section 5 profiles the GSAKMP requirements on its underlying IPsec
subsystem that assure inter-operability between all GSAKMP IPsec
endpoints and co-existence with IKE-v2 [IKE-V2].
1.3 GSAKMP IP Security Policy Token Extension
The GSAKMP IP Security policy token extension manages the group's
one or more Group Security Association (GSA) and other security
policy configuration for an RFC2401-bis compliant Security Policy
Database (SPD), Security Association Database (SAD), and the Peer
Authorization Database (PAD). The GSAKMP IPsec policy token
extension is an application specific branch under the GSAKMP core
policy token schema [COREPT]. The GSAKMP IPsec policy token design
is a subset of the IP security policy information model [RFC3585]
with accommodations for secure multicast and the architectural
features present in RFC2401-bis. The SNMP SPD configuration MIB
[SPDMIB] is another major design influence on the GSAKMP IPsec
policy information model. This document only introduces the IPsec
policy token concepts; reference [IPSECPT] formally specifies the
GSAKMP IPsec policy token extension.
1.4 NACK Oriented Reliable Multicast Protocol Profile
GSAKMP depends on a reliable multicast transport layer to deliver
its group-wide multicast messages. In particular, the GSAKMP GC/KS
multicasts the Re-Key Event (RKE) message containing the GSAKMP
IPsec policy token and group re-keying material to all of the
group's members. The RKE message is often large enough that when it
is fragmented to match the multicast path maximum transmission unit
size, the RKE becomes susceptible to unacceptably high error rates.
The GSAKMP base specification only defines a simple time-out based
retransmissions scheme and it does not specify the reliable
multicast transport layer. This document specifies a profile on the
Negative-acknowledgement Oriented Reliable Multicast (NORM) protocol
[NORM] that is more robust against GSAKMP multicast message fragment
losses than simple multicast retransmission over UDP. Section 8
specifies the NORM protocol profile.
Gross Expires January, 2004 page 7
GSAKMP Application to the IP Security Architecture July, 2004
1.5 Interactions with NAT and Mobility
The GSAKMP IP Security mapping must accommodate the negative impact
of IP-v4 Network Address Translation (NAT) [RFC2663] [RFC3022] and
mobility induced changes in a multicast speaker's source IP address.
Both of these issues require a GSAKMP mechanism to synchronize a
group's SPD/SAD traffic selectors with unannounced changes in the
Internet layer's state. The absence of a SPD/SAD synchronization
mechanism can cause the group's data traffic to be discarded rather
than processed correctly. NAT and mobility are also at the root of a
litany of secondary GSAKMP architectural problems that would also
benefit from a solution.
This specification defines a new GSAKMP protocol extension, the
"Security Association Management" (SAM) message, which mitigates
these problems by announcing to the GSAKMP group membership any
changes in a multicast speaker's IP interface address set. A GSAKMP
IPsec implementation may offer access to its Secure Identity Address
Mapping (SIAM) database (see (C2) in figure 1) to those peer
components that need to know these authenticated mappings. Section 6
examines these NAT and mobility problems and section 7 goes on to
specify the SAM message solution.
1.6 Group Speaker Security Association Management
The GSAKMP IPsec application treats the Group Speaker role as a
security policy managed privilege. The motivation is the observation
that in the absence of per packet source authentication, multicast
can be a powerful tool in a denial of service attack. The GSAKMP
IPsec application introduces the Security Association Management
(SAM) message as part of a new Group Speaker authorization process.
An important SAM message benefit is that it allows a Group Speaker
to independently manage its set of GSA within the constraints
dictated by the IPsec policy token. The Group Speaker does not incur
the overhead of a policy token revision signed by the Group Owner
every time that the Group Speaker creates, modifies, or destroys one
of its GSA.
1.7 Public Key Infrastructure Profile
The GSAKMP IPsec mapping is inter-dependent with a Public Key
Infrastructure (PKI)characterized by diversity in its standards and
its deployments. This specification profiles those aspects of GSAKMP
Identification payloads, X.509v3 public key certificate fields, and
GSAKMP Certificate payloads needed to assure that conformant GSAKMP
Gross Expires January, 2004 page 8
GSAKMP Application to the IP Security Architecture July, 2004
IPsec implementations can be configured to inter-operate with each
other and with a standards-based PKI deployment. A major influence
on this profile is [PKI4IPSEC]. However, this specification and its
successors takes precedence for the GSAKMP IPsec profile. Section 9
specifies the PKI related profile parameters, including those
aspects that must be configurable at the PKI management interface.
2 Terminology and Definitions of Terms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
This document makes reference to the following terms, acronyms, and
definitions:
. AH - Authentication Header
. Composite group
. DSCP - Differentiated Services Control Point
. ESP - Encapsulating Security Payload
. GC/KS - Group Controller/Key Server
. GM - Group Member
. GO - Group Owner
. Group Receiver
. Group Speaker
. GSA - Group Security Association
. GTAK - Group Traffic Authentication Key
. GTEK - Group Traffic Encryption Key
. ITAM - Identity to Transient Address Mapping GSAKMP payload
. KDL - Key Down-Load message
. Leading edge GSA
Gross Expires January, 2004 page 9
GSAKMP Application to the IP Security Architecture July, 2004
. NAT - Network Address Translation
. NAPT - Network Address/Port Translation
. Node
. Node Identity
. NORM - Negative-acknowledgement Reliable Multicast protocol
. PAD - Peer Authorization Database
. PKI - Public Key Infrastructure
. Primary-GC/KS
. RKE - Re-Key Event message
. RTD - Request-To-Depart message
. RTJ - Request To Join message
. SAC - Security Association Configuration GSAKMP payload
. SAD - Security Association Database
. SAM - Security Association Management message
. SIAM - Secure Identity to Address Mapping database
. SPD - Security Policy Database
. SPI - Security Parameter Index
. Subordinate GC/KS
. TEBAC - Transport Endpoint Binding Attribute Certificate
. Trailing edge GSA
. Transport endpoint identifier
. UDP - User Datagram Protocol
Gross Expires January, 2004 page 10
GSAKMP Application to the IP Security Architecture July, 2004
3 GSAKMP IPsec Identifier and Addressing Architecture
The GSAKMP IPsec application defines a set of identifier name space
conventions that assure inter-operable usage and allocation of the
objects and architectural entities referenced by the GSAKMP IPsec
policy token.
The GSAKMP IPsec policy token in combination with a SAM message
configures the group's SPD traffic selectors at both the Internet
and transport protocol layers. To assure interoperable GSAKMP
implementations, this section explains the information model
relationships between the identifiers found at the Internet layer's
multicast service, the multicast transport layer, and the multicast
application layer.
3.1 GSAKMP Group Node Identity
GSAKMP IPsec groups require a multicast application endpoint
addressing scheme wherein the endpoint's Node identifier remains
constant despite a GSAKMP group's membership straddling two sources
of change in its IP addresses:
- A mobile Node will change one or more of its IP interface
addresses after each move between IP networks. These changes in IP
address make it difficult to depend on an IP source address for
the source-specific multicast security policies configured in the
group's SPD traffic selectors.
- Secure multicast GSA interactions with IP-v4 Network Address
Translation (NAT) gateways also negatively impact those SPD
entries that refer to source IP-v4 addresses. Refer to section 6
for an explanation.
The "Node Identity" is the permanent GSAKMP IPsec handle that refers
to the IP protocol stack (and its companion IPsec subsystem)
residing within a physical Node. Unlike the Node's one or more
transient IP interface addresses, the Node Identity does not change
when the Node changes its location. Since the Node Identity is
constant, the Group Owner can consistently enforce its security
policies with respect to a Node Identity. See [NSRG] for additional
architectural motivation.
A Node Identity is structured as an IP-v6 address, but it is not
intended to be unicast routable in the global Internet. Instead, it
Gross Expires January, 2004 page 11
GSAKMP Application to the IP Security Architecture July, 2004
is better understood as an Internet layer Node identifier bound to a
transient set of one or more locator IP addresses.
3.1.1 Node Identity as a Unicast IP-v6 Address
Regardless of whether a GSAKMP group will be using IP-v6 or IP-v4 as
its multicast datagram delivery service, the Group Owner MUST assign
each Node participating in a GSAKMP group a "Node Identity" IP-v6
address. A Node Identity is a globally unique local unicast IP-v6
address as defined by [LCLUNIQ]. The Group Owner permanently
allocates the Node Identity from a network prefix reserved for the
exclusive use of the GSAKMP groups that the Group Owner
administratively owns and manages. Note that the Node Identity's
lifetime transcends a particular group membership cycle. In other
words, a Node joins a group using the same Node Identity across all
instances of its membership in any group managed by the Node's Group
Owner.
The Node Identity comprises the following fields:
- Globally unique local unicast address prefix: FC00::/7.
- GSAKMP Group Owner's global identifier prefix, 40 random bits - as
described in [LCLUNIQ] section 3.2. One additional bit selects
central versus local prefix assignment. The global identifier
prefix MUST NOT have the value of zero. The GSAKMP group network
prefix MUST NOT be an IP-v6 prefix delegation from a RIR or ISP.
Instead, the Group Owner MUST allocate its GSAKMP network prefix
from the IP-v6 globally unique local unicast address space. This
provider independent network prefix MAY be generated pseudo-
randomly by a local procedure, or it MAY be allocated by the
central allocation authority that assures its global uniqueness
within the IP-v6 address pool. The Group Owner management
interface MUST support both allocation procedures.
- GSAKMP group sub-net identifier, 16 bits - This field corresponds
to the "sub-net identifier" field defined in [LCLUNIQ]. When not
explicitly set by policy, the GSAKMP group sub-net identifier
SHOULD be set to a default value of zero. The Group Owner MAY
assign non-zero GSAKMP group sub-net identifiers to represent
policy defined Node Identity ranges or aggregates. GSAKMP group
sub-net identifiers make it convenient for SPD traffic selectors
to enforce security policies on logical subsets of a group's
membership. For example, a group sub-net identifier MAY refer to
the Node population that belongs to a sub-group within a composite
Gross Expires January, 2004 page 12
GSAKMP Application to the IP Security Architecture July, 2004
group (see section 5.11.1). The GSAKMP group sub-net identifier
SHOULD NOT represent a sub-group's topological point of attachment
to the global Internet. A Node MAY have multiple Node Identities
that are aliases for the same physical Node, each alias having a
distinct GSAKMP group sub-net identifier but a common Interface
Identifier. Each such alias has an associated Node Identity public
key certificate, although all of the certificates refer to the
same key pair..
- Interface Identifier, 64 bits - The Group Owner MUST assign this
value to be unique relative to all other Nodes for which it
controls the GSAKMP group memberships. The Modified EUI-64 "u" bit
MUST be set to zero (i.e. local scope). The Group Owner SHOULD
assign the Interface Identifier's value to be the low-order 64
bits of the Node Identity's public key. If a Node is registered
with multiple Group Owner's, then its Node Identity's Interface
Identifier SHOULD be the same value across all of those Group
Owners.
3.1.2 Node Identity Public Key Certificate
A Node MUST have an associated X.509 end-entity signature
certificate with its IP-v6 address "SubjectAltName" field set to the
Node Identity IP-v6 address. Section 9.4 profiles this certificate.
The Node Identity MUST have a valid certificate path rooted at one
of the GSAKMP group's trust anchor Certificate Authorities. The
Group Owner MAY be the Node Identity's Certificate Authority. The
Node Identity's signature substantiates its assertions about its
interface IP addresses, and proxies the signatures of the
application endpoints that reside on that Node.
3.1.3 Secure Identity to Address Mapping Database
Each Node in a GSAKMP group maintains a Secure Identity Address
Mapping (SIAM) database. The SIAM database contains the Node
Identity to transient IP address set mappings for all of the
relevant peer Nodes in the group. See section 7 for the discussion
of how a Node populates its SIAM.
One of the GSAKMP IPsec implementation's responsibilities is
maintaining an accurate 1:1 mapping in the SIAM database between the
dynamic 4-tuple:
- Source transient IP address (either IP-v4 or IP-v6),
Gross Expires January, 2004 page 13
GSAKMP Application to the IP Security Architecture July, 2004
- Source transient IP-v4 address after NAT gateway translation,
- Destination multicast IP address (either IP-v4 or IP-v6).
- Security Association's Security Parameter Index
And the corresponding static 3-tuple representing a multicast
application Group Speaker endpoint:
- Group Speaker Node Identity,
- Next layer protocol identifier,
- Multicast application's source port number,
RFC2401-bis compliant SPD traffic selectors refer to the transient
IP addresses rather than quantities that remain stable during a
group membership life span. Consequently, GSAKMP IPsec defines an
efficient yet secure GSAKMP protocol extension, the Security
Association Management message, to synchronize the group's SPD
traffic selectors whenever there is an update to the above mapping.
See section 7 for more information about this mechanism.
3.2 GSAKMP IPsec Group Identifier
The "GSAKMP IPsec Group Identifier" MUST be an "IP-v6" Group
Identification type as defined by [GSAKMP] section 7.1 table 11. The
GSAKMP IPsec Group Owner assigns the GSAKMP IPsec Group Identifier
by combining three components:
. GSAKMP group serial number _ A permanent pseudo-random unsigned 64
bit serial number that is unique relative to all of the GSAKMP
IPsec groups created and managed by the Group Owner. In [GSAKMP]
section 7, this component is referred to as a "Random Value",
although it remains constant for the duration of the group's
lifetime.
. Group Owner's global identifier prefix, which is the high-order 48
bits of a Node Identity as defined in section 3.1.
. IP-v6 group identifier, an unsigned 32-bit integer that is unique
relative to the Group Owner global identifier prefix. The IP-v6
group identifier MUST be a dynamic group allocation from the range
specified in [RFC3307] section 4.3.1 for a server address
allocation.
Gross Expires January, 2004 page 14
GSAKMP Application to the IP Security Architecture July, 2004
The GSAKMP IPsec Group Identifier when further qualified by a four
octet sequence number refers to a particular GSAKMP IPsec policy
token that the Group Owner has issued for that GSAKMP group. The
sequence number SHOULD advance monotonically by one for each policy
token signed by the Group Owner.
When encoded as the Group ID Value within a GSAKMP header, the
GSAKMP IPsec Group Identifier complies with [GSAKMP] section
7.1.1.1.4, with the IP-v6 value field set to the group's IP-v6
multicast address as defined by this document's section 3.5 (or
section 3.6 if the group uses Source-Specific Multicast).
3.3 GSAKMP IPsec Transport Layer Endpoint Identifier
A GSAKMP IPsec transport layer endpoint identifier refers to an
active group membership held by an application endpoint within a
Node. Typically, a transport layer endpoint is instantiated as a
individual process or file descriptor (e.g. socket) within a Node.
Other equivalent implementation mechanisms are possible, but for the
sake of clarity of exposition this specification refers to the well-
known socket model.
3.3.1 Transport Layer Endpoint Identifier Definition
A GSAKMP IPsec transport layer endpoint identifier is a 3-tuple
formed from the following components:
- Node Identity of the Node hosting the application endpoint, as
defined in section 3.1.
- Next layer protocol identifier _ Identifies the multicast
application's transport layer protocol(e.g. UDP or a reliable
multicast transport protocol).
- Multicast application source port number _ The transport layer
identifier dynamically assigned by a Node to represent a multicast
application's endpoint context state. For example, an
application's endpoint context state could be a socket file
descriptor.
The Node MUST assign a transport layer endpoint instance its source
port number before the GC/KS authorizes that application's endpoint
to become a GSAKMP group member. The source port number when
qualified by its next layer protocol identifier MUST be unique
relative to all other source port numbers assigned by that Node. The
Gross Expires January, 2004 page 15
GSAKMP Application to the IP Security Architecture July, 2004
source port number is GSAKMP group-wide unique when qualified by its
Node Identity and next layer protocol identifier. Associated with
each transport layer endpoint instance are the following properties:
- GSAKMP IPsec Group Identifier without its policy token sequence
number qualifier, as defined in section 3.2.
- Group Speaker endpoint mode or Group Receiver endpoint mode
- Multicast application destination port number _ The multicast
application's statically assigned transport layer identifier. The
destination port number has the same value across all endpoints
participating in the multicast application. Generally, the
multicast application destination port number is configured to
imply a particular GSAKMP IPsec Group Identifier. However, an
implementation defined mechanism MAY dynamically choose the
binding between an application and a GSAKMP group.
Within a Node, multiple Group Receiver transport layer endpoints
could open and bind to the same multicast application destination
port number using an implementation defined mechanism. Each
authorized endpoint receives a decrypted copy of the group's
multicast transmissions addressed to that destination port number.
For the multicast application's Group Speaker transport layer
endpoints, one or more endpoints on a common Node could register
with a GSAKMP group using an implementation defined mechanism. Once
the GC/KS authorizes a transport layer endpoint to become a Group
Speaker, then that endpoint can transmit encrypted datagrams to the
GSAKMP group. The multicast datagrams originating from a Group
Speaker endpoint will have a unique source port number relative to
the datagrams originating from the other multicast speakers on the
same Node.
3.3.2 Application Endpoint Signature Certificate
At the GSAKMP IPsec application layer, an X.509 signature identity
represents the application endpoint. The application endpoint signs
an attribute certificate that binds its X.509 signature identity to
a transport layer endpoint identifier and a Node Identity.
Every application endpoint participating in a GSAKMP group MUST have
a X.509v3 signature public key certificate with a valid certificate
path rooted at one of the GSAKMP group's trust anchor Certificate
Gross Expires January, 2004 page 16
GSAKMP Application to the IP Security Architecture July, 2004
Authorities. It MUST possess the corresponding signature secret key
for that public key. Section 9.2 defines this certificate's profile.
The application endpoint's signature certificate should not be
confused with the Node Identity certificate described in section
3.1.2. The former certificate is an application layer endpoint
identity, whereas the Node Identity certificate represents an
Internet layer identity (e.g. the Node's operating system). There
may be one or more multicast application endpoint identities co-
resident on a common Node, each with its own signature public key
certificate and associated secret key.
3.3.3 Transport Endpoint Binding Attribute Certificate
An application endpoint's signature identity does not necessarily
represent an application process itself, rather it may be
representing an end user's identity. In such cases, an end user
visiting a Node would have only a temporary relationship with that
Node. The GSAKMP IPsec application uses a "Transport Endpoint
Binding Attribute Certificate" (TEBAC) to cryptographically bind the
application endpoint identity and the Node Identity.
Whenever an application endpoint requires GSAKMP group management
services, it first issues a TEBAC that delegates to its Node's
GSAKMP subsystem the authority to:
. Sign the GSAKMP registration or de-registration protocol messages
that the Node exchanges with the GC/KS. The GSAKMP subsystem
proxies the application endpoint's signature by signing with its
Node Identity secret key.
. Bind the transport endpoint identifier to the application
endpoint's X.509 identity as expressed by its signature
certificate.
. If in Group Speaker mode, create and modify entries in the Group
Receiver endpoints SPD/SAD whenever there is a change in the
Node's set of IP addresses. As needed, the Group Speaker's GSAKMP
subsystem multicasts a Security Association Management message
that installs these SPD/SAD modifications.
. If using a multicast source authentication service, sign the ESP
or AH protected payloads sent by the multicast application's
protocol.
Gross Expires January, 2004 page 17
GSAKMP Application to the IP Security Architecture July, 2004
The TEBAC is the output of a local mutual authentication and
authorization process between an application endpoint identity and a
Node Identity. Although that process is an implementation matter
between the Node and the application endpoint, this standard does
mandate that process MUST generate a TEBAC conforming to the profile
in section 9.6. The TEBAC creation MUST occur before the multicast
application endpoint attempts its request to join a GSAKMP group.
The TEBAC MUST be among the GSAKMP RTJ message's Certificate
payloads. This requirement also applies to the GSAKMP Request-To-
Depart message Certificate payloads.
The TEBAC "Issuer" field MUST refer to the application endpoint's
end-entity signature certificate. Consequently, the certificate's
Issuer signature is that of the application endpoint's secret key.
The TEBAC attribute fields declare:
. GSAKMP IPsec group identifier,
. Group Speaker mode or Group Receiver mode,
. Destination port number,
. Transport endpoint identifier (see section 3.3.1).
The certificate's "Holder" field MUST refer to the Node Identity's
signature certificate. That certificate's identity is the same as
the signer identity that will be used in the forthcoming GSAKMP
message's Signature payload. The TEBAC validity period is a matter
of local policy, but it MUST at least exceed the expected duration
of the GSAKMP protocol exchanges that depend on that TEBAC.
3.4 Receiver Multicast Packet Distributor Identifier
Section 5.11 defines the Multicast Packet Distributor policy action
component. The Receiver Multicast Packet Distributor is uniquely
identified by the 3-tuple:
- Group Identifier without its policy token sequence number
qualifier, as defined in section 3.2. The Group Identifier implies
the next layer protocol identifier and the multicast application's
destination port number.
- Multicast receiver's Node Identity,
Gross Expires January, 2004 page 18
GSAKMP Application to the IP Security Architecture July, 2004
- GSAKMP group's time epoch, expressed as the GSAKMP group
identifier's policy token sequence number
3.5 GSAKMP Group Any Source Multicast IP-v6 Address
For a GSAKMP IPsec group using an IP-v6 any-source multicast routing
service, its IP-v6 multicast address SHOULD be a unicast-prefix-
based IPv6 multicast address [RFC3306] [RFC3513] defined as follows:
- High-order 8 bits, all ones,
- Flags field: The transient group "T" bit must be one except as
noted below, the prefix "P" bit must also be one.
- Scope field: set as described below,
- Reserved field, 8 bits of all zeros (see note below regarding an
embedded Rendezvous Point address),
- Prefix length field, set to 48
- Unused portion of the network prefix field: 16 bits set to zeros,
- Globally unique local unicast prefix: FC00::/7
- Local/central authority prefix allocation bit,
- Group Owner global identifier prefix, 40 bits
- IP-v6 group identifier as per section 3.2, 32 bits
The address's "transient group" bit flag MUST be set unless the
GSAKMP group is permanently allocated by IANA. It is RECOMMENDED
that the scope be set to either admin-local, site-local, or
organization-local. The Group Owner management interface MUST
provide the ability to configure the multicast address scope to any
legal value. The Group Owner management interface SHOULD provide the
ability to configure the Embedded Rendezvous Point address
capability [EMBEDRP]. This capability assigns a 4 bit-wide field
within the above reserved field for the embedded Rendezvous Point's
interface identifier.
Gross Expires January, 2004 page 19
GSAKMP Application to the IP Security Architecture July, 2004
3.6 GSAKMP Group Source-Specific Multicast IP-v6 Address
For usage with an IP-v6 source-specific multicast routing service,
the GSAKMP group's unicast prefix-based IPv6 source-specific
multicast address SHOULD use the format defined by RFC3306 section
6. The address's low-order 32 bits are the IP-v6 group identifier as
defined in section 3.2. The Group Owner management interface SHOULD
provide the ability to configure the Embedded Rendezvous Point
address capability [EMBEDRP].
When the GSAKMP group uses IP-v6 Source-Specific Multicast, then a
multicast speaker Node SHOULD NOT use its Group Owner assigned Node
Identity as its IP-v6 source address for the multicast datagrams
that it sends to that GSAKMP group. Instead, the multicast speaker
Node MUST use one of the IP-v6 interface addresses declared in its
most recent verified Identity to Transient Address Mapping payload.
3.7 GSAKMP Group Multicast IP-v4 Address
For a GSAKMP group using IP-v4 multicast service, the IP-v4
multicast address SHOULD be algorithmically derived from the GSAKMP
group's IP-v6 multicast address. RFC2529 section 6 [6over4] defines
this multicast address derivation procedure. The Group Owner
management interface MAY provide the ability to configure an
administratively defined alternative GSAKMP group IP-v4 multicast
address.
4 GSAKMP IP Security Implementation Profile
This section of the GSAKMP IP Security application encompasses three
facets of a GSAKMP implementation:
- Those attributes and behaviors relevant to when two GSAKMP IPsec
implementations are interacting with one another through the
unicast GSAKMP protocol exchanges. In figure 1, these protocol
exchanges flow over the data path labeled (D3).
- The GSAKMP Re-Key Event multicast message and its Re-Key Group
Security Association. In figure 1, these protocol exchanges flow
over the data path labeled (D2).
- GSAKMP management interface configuration capabilities that assure
that two independent GSAKMP IPsec implementations can be arranged
to inter-operate.
Gross Expires January, 2004 page 20
GSAKMP Application to the IP Security Architecture July, 2004
4.1 GSAKMP Security Suite 2
The GSAKMP IPsec mapping Security Suite 2 is a superset of the
Security Suite 1 as defined in GSAKMP section 6. Compliant GSAKMP
IPsec implementations MUST support the algorithms specified by
Security Suite 1 and in addition they MUST support:
- Group Owner's policy token digital signature algorithm of RSA with
a hash algorithm of MD5 [RFC3447].
- GSAKMP message signature algorithm of RSA with a hash algorithm of
MD5.
4.2 Group Re-Keying Algorithm and Protocol
The GSAKMP IPsec implementation MUST support Logical Key Hierarchy
(LKH) as defined by GSAKMP appendix A. A GSAKMP IPsec implementation
MAY support the group re-key protocol and algorithm specified in
this document's Appendix A. The GSAKMP IPsec re-keying philosophy is
to batch group join and group leave events into a periodic Re-Key
Event (RKE) multicast. The benefit is to minimize re-keying overhead
even when there is a high membership turnover. In figure 1, the RKE
multicast is the data flow labeled (D2).
Group policy sets the RKE multicast transmissions frequency. The RKE
reliable delivery by default MUST use the NORM protocol (see section
8 for details) and it MAY be configurable on a per group basis to
use UDP or another reliable multicast transport protocol besides
NORM. The GSAKMP Group Owner management interface MUST provide the
ability to adjust the RKE frequency and the associated group keying
material lifetime on a per GSAKMP group basis. The RECOMMENDED
minimum re-key interval should be tuned to be longer in duration
than the NORM protocol's predicted maximum error recovery time.
When the RKE multicast is a NORM protocol payload, the NORM|GSAKMP
message is encapsulated within a UDP header having the UDP
destination port number GSAKMP-NORM-UDP (see section 11.1). The
UDP|NORM|GSAKMP payload in turn is ESP protected by the Re-Key GSA.
The GSAKMP Group Owner management interface SHOULD have the ability
to configure the parameters used by the underlying NORM protocol
subsystem on a per group basis.
GSAKMP IPsec implementations MUST be able to receive a RKE message
up to 65,535 bytes long.
Gross Expires January, 2004 page 21
GSAKMP Application to the IP Security Architecture July, 2004
4.3 GC/KS Re-Key Group Security Association
A bi-directional Re-Key Group Security Association protects each
GC/KS NORM session. See section 5.3.2 for the definition of a bi-
directional GSA. Figure 1 shows the Re-key GSA data flow at label
(D2). The Re-Key GSA exists for the same lifetime as the multicast
application's one or more GSA shown at figure 1 labels (D0) and
(D1).
When a GSAKMP group operates in the autonomous distributed GC/KS
mode (see [GSAKMP] section 4.4.7), then there is a Re-Key GSA for
the Primary-GC/KS and a separate Re-Key GSA for each Subordinate-
GC/KS. The P-GC/KS GSA membership comprises the P-GC/KS and its one
or more S-GC/KS. The S-GC/KS GSA membership is the sub-group of the
multicast application's group membership that the S-GC/KS admitted
into the group and thereafter manages.
The GC/KS is the only authorized multicast speaker in the Re-Key
GSA. The Re-Key GSA MUST use the IPsec anti-replay protection
service for the GC/KS multicast RKE transmission. The Re-Key GSA
multicast transmission MUST have a distribution scope that assures
all group members under the management control of their GC/KS will
receive the Re-Key Event message.
In the group member to GC/KS direction, the Re-key GSA MUST NOT have
IPsec anti-replay service enabled. The SPD MUST be setup to allow
any currently authorized group member to send a unicast NORM-NACK
repair request (or other NORM message) to the GC/KS. If the facility
is available, then all NORM messages SHOULD be source authenticated
and verified by the GC/KS as belonging to the currently authorized
group membership. The GC/KS SHOULD discard messages received from
expelled or departed group members before NORM is allowed to process
the message. Section 8 defines the NORM profile on which the Re-Key
GSA depends.
4.4 Verbose Mode
GSAKMP IPsec implementations MUST support Verbose mode. The GSAKMP
Group Owner management interface MAY provide the ability to
configure Verbose or Terse mode behavior on a per GSAKMP group
basis.
Gross Expires January, 2004 page 22
GSAKMP Application to the IP Security Architecture July, 2004
4.5 Identification and Signature's Identifier Types
Section 9.1 defines the Identification payload ID types defined by
[GSAKMP] table 17 that MUST be supported by the registration and de-
registration protocol exchanges. Section 9.1 also defines the
Signature payload signer ID types declared by [GSAKMP] table 20 that
MUST be supported by the registration and de-registration protocol
exchanges.
4.6 Lack Of Acknowledgement (LOA) Message
The GSAKMP IPsec implementation MUST send and receive the LOA
message as defined in GSAKMP section 5.2.1.5. The RECOMMENDED GC/KS
timeout interval for sending a LOA is 6 seconds. The Group Owner
management interface MAY configure the GC/KS to not send LOA on a
per GSAKMP group basis.
4.7 Registration Exchange Transport Layer Parameters
The GSAKMP IPsec registration protocol exchange MUST use UDP as its
transport layer protocol and it SHOULD NOT use the UDP checksum
feature for its signed GSAKMP messages. The RECOMMENDED number of
retransmission attempts is 3, with a timeout interval of 3 seconds
between retries. It is RECOMMENDED that a candidate group member
that receives a RTJ-ERROR response to its RTJ transmission will wait
9 seconds for a delayed Key-Down-Load (KDL) message before giving up
and releasing its registration security association state.
The GSAKMP IPsec implementation SHOULD provide a local management
interface that can tune each of the registration protocol exchange's
recommended transport layer parameter values.
4.8 GSAKMP Registration Protocol Exchange Extension
The GSAKMP IPsec application explicitly authorizes each of a group's
multicast speakers by extending the base GSAKMP registration
protocol exchange.
Whenever mobility or NAT changes a Group Speaker's transient source
IP address, the group's security policy decides how to announce that
change to the Group Receiver endpoints. In a strict policy, the
Group Speaker must prove the return route-ability of its asserted
new source IP address. The Group Speaker executes a GSAKMP re-
registration protocol exchange extension to revise the group's view
of that address. In a relaxed security policy, the Group Speaker
Gross Expires January, 2004 page 23
GSAKMP Application to the IP Security Architecture July, 2004
simply multicasts a Security Association Management message
containing an ITAM payload that asserts its new set of IP addresses
without substantiation.
If a Group Receiver endpoint wants to become a Group Speaker then it
MUST re-register with group using a newly created TEBAC that
declares a new source port number and requests Group Speaker role
authorization.
The GSAKMP IPsec application makes the following registration
protocol exchange extensions to the procedures specified in [GSAKMP]
section 5.2. Both candidate Group Receiver and candidate Group
Speaker endpoints MUST execute these registration extensions:
1. Prior to starting the registration protocol exchange, the
application endpoint MUST generate an Transport Endpoint Binding
Attribute Certificate as described in section 3.3.3.
2. All GSAKMP IPsec candidate Group Member endpoints, both speakers
and receivers, MUST be capable of participating in a cookies
exchange as defined in [GSAKMP] section 5.2.2.. A candidate Group
Speaker and the GC/KS MUST exchange cookies. The cookies exchange
proves return route-ability for the candidate Group Member's
transient IP address location asserted in the ITAM payload. The
Group Owner management interface MUST be able to configure the
cookie exchange policy on a per group basis; by default it SHOULD
be enabled.
3. The candidate Group Member's Request-To-Join (RTJ) message sent to
the GC/KS MUST include the following two payload extensions beyond
those defined by the GSAKMP base protocol:
. Identity to Transient Address Mapping (ITAM) GSAKMP payload -
The ITAM payload describes the Group Member's Node Identity
mapping to one or more transient locator IP addresses. Section
7.4 describes the ITAM payload.
. Transport Endpoint Binding Attribute Certificate payload _ The
TEBAC substantiates a Node Identity's assertion that it is the
delegated GSAKMP message signer on behalf of the application
endpoint identifier that issued the TEBAC.
4. The GC/KS checks for the following possible GSAKMP IPsec
registration error conditions when processing the RTJ:
Gross Expires January, 2004 page 24
GSAKMP Application to the IP Security Architecture July, 2004
. The TEBAC certificate's GSAKMP IP-v6 group identifier found in
the Group attribute field MUST match the GSAKMP IP-v6 group
identifier found in the RTJ message's GSAKMP header.
. The TEBAC certificate's "Issuer" field MUST refer to the
application endpoint's end-entity signature certificate. The
certificate's Issuer signature MUST be valid, including a valid
certificate path to one of the group's trusted anchor CA.
. The TEBAC certificate's "Holder" field MUST refer to the Node
Identity's end-entity signature certificate, and that
certificate's identity MUST be the same signer identity as is
found in the RTJ message's Signature payload.
. The Signature payload's signature MUST be valid, it MUST be the
Node Identity's signature, and it MUST have a valid certificate
path to one of the group's trusted anchor CA.
. The TEBAC validity period MUST NOT be expired.
. The TEBAC declared Node Identity MUST match the Node Identity
contained in the ITAM payload.
. A proposed Group Speaker endpoint MUST be authorized as a Group
Speaker: If the TEBAC transport endpoint identifier attribute
field "S" flag is set, then the candidate Group Member requests
the authority to become a Group Speaker. The GSAKMP IPsec
policy token contains Group Speaker authorization pattern
matching rules, analogous to those used for the group
membership and GC/KS role authorizations. The GC/KS MUST apply
those Group Speaker authorization rules as part of its request
to join admittance decision.
. One of the ITAM payload's interface IP addresses MUST contain
the transient source IP address that had been verified by the
cookies exchange.
. The TEBAC attribute fields MUST conform to the group's policy
token: the TEBAC attribute fields assert a valid destination
port number and transport endpoint identifier.
If the GC/KS discovers any one of the above error conditions while
processing the RTJ then the GC/KS responds to the candidate group
member with a RTJ-ERROR message. The RTJ-ERROR message contains a
Gross Expires January, 2004 page 25
GSAKMP Application to the IP Security Architecture July, 2004
Notification payload having the error status "Not authorized to
speak to the group" if the TEBAC "S" flag is set.
5. If the GC/KS admits the candidate Group Member into the group,
then it prepares a Key-Download (KDL) message to send to the Group
Member. The GC/KS signs the KDL with its Node Identity. The KDL
message's Identification payload refers to the TEBAC Issuer
application endpoint identity. The GC/KS keeps a local copy of the
Group Member's TEBAC so that it can verify the Signature payload
of the forthcoming KDL-ACK/NACK response. The GC/KS MUST include
two or more SAC payloads in the KDL message sent to the new Group
Member. See section 7.5. The new Group Member MUST be sent a SAC
payload that describes its Re-key GSA SPD/SAD entry. For a new
Group Speaker, a second SAC payload creates the SPD/SAD entry for
the speaker's leading edge GSA. For a new Group Receiver, the KDL
contains a separate SAC payload for each peer Group Speaker GSA
that is speaking to the group. The new Group Receiver creates its
SPD/SAD entries from these SAC payloads.
6. For a GC/KS straddling an IP-v4 public/private network boundary,
the KDL message SHOULD include an ITAM payload containing a single
interface IP address structure. The structure encodes the GC/KS
public IP-v4 address as the high-order 32 bits of the Interface
Identifier field. The Interface Identifier field's low-order 32
bits are the Group Member's private IP-v4 address that has been
verified by the GC/KS using the cookies exchange. The IAT field is
set to b'01'. Section 7.4 describes the ITAM payload.
7. If the Group Member accepts the KDL, then the Group Member
responds to the GC/KS with a Key-Download-Acknowledgement (KDL-
ACK) message signed by the Group Member's Node Identity. The Group
Member MAY include the TEBAC in a Certificate payload.
8. If the Group Member does not accept the KDL, then the Group Member
responds with a KDL-NACK message signed by the Group Member's Node
Identity secret key. The Group Member MAY include the TEBAC in a
Certificate payload.
9. If the Group Member fails to respond with KDL-ACK or KDL-NACK,
within the allotted time, then the GC/KS sends a LOA signed by its
Node Identity secret key.
10. If the new Group Member is a Group Speaker, then it multicasts
a Security Association Management (SAM) message to the GSAKMP
group. The SAM message revises the Group Receiver endpoint SPD/SAD
Gross Expires January, 2004 page 26
GSAKMP Application to the IP Security Architecture July, 2004
entries, installing a new leading edge GSA that will decrypt the
Group Speaker's future transmissions. The new SAM specified
SPD/SAD policy displaces the group's default policy that would
have discarded the multicast transmissions from an unknown source.
4.9 De-Registration Security Association Protocol Exchange
GSAKMP IPsec implementations MUST support the de-registration
protocol exchange, although a given group's policy MAY choose not to
require the use of that protocol exchange. When a group is in
autonomous distributed mode (section 4.10), the Group Member's de-
registration protocol exchange MUST be with the same GC/KS as the
group member had used for its registration protocol exchange.
The Request-To-Depart message received at the GC/KS from a departing
Group Member MUST have a valid TEBAC Certificate payload and an
authorized Node Identity signature in its Signature payload. The
TEBAC MAY be the same TEBAC as was used during registration. Its
verification process is identical to that specified for the GSAKMP
registration protocol exchange. The GC/KS signs its Departure-
Response message with its Node Identity secret key. The Departure-
Response message's Identification payload refers to the TEBAC
"Issuer" application endpoint identity.
The GSAKMP IPsec de-registration protocol exchange MUST use UDP as
its transport layer protocol and it SHOULD NOT use the UDP checksum
feature for the signed GSAKMP messages. The RECOMMENDED number of
retransmission attempts is 3, with a timeout interval of 3 seconds
between retries. The GSAKMP IPsec implementation SHOULD provide a
local management interface that can tune each of the de-registration
protocol exchange's recommended parameter values.
A Group Speaker that wants to revise the group's view of its source
transient IP address does not have to do a de-registration protocol
exchange before it begins its re-registration protocol exchange.
4.10 GSAKMP Autonomous Distributed Mode
The GSAKMP autonomous distributed mode enables large-scale groups,
wherein the Primary-GC/KS delegates group membership management
responsibilities to one or more Subordinate-GC/KS. Each S-GC/KS
handles a sub-group within the overall group membership. Section
5.11.1 discusses the composite group facility, which can be applied
to this scenario.
Gross Expires January, 2004 page 27
GSAKMP Application to the IP Security Architecture July, 2004
GSAKMP IPsec IP-v6 endpoints SHOULD support GSAKMP autonomous
distributed mode. GSAKMP IPsec IP-v4 endpoints that participate in a
multi-realm GSAKMP group that spans multiple IP-v4 private networks
(i.e. a GSAKMP group that has NAT gateways present) MUST support
GSAKMP autonomous distributed mode. Refer to section 6.4 for
details.
The GSAKMP IPsec local management interface MUST provide the
capability to configure a Node to operate in a S-GC/KS or GM role on
a per GSAKMP group basis. If the Group Owner supports group in
autonomous distributed mode, then the Group Owner management
interface MUST provide the ability to configure autonomous
distributed mode on a per group basis
4.11 Group Owner Management Interface
This sub-section describes those GSAKMP Group Owner management
interface requirements that are not specified elsewhere in the
GSAKMP IPsec mapping specification:
1. Generate "public announcements" that discloses the subset of a
GSAKMP group's security policies sufficient to allow interested
candidate members to know which GC/KS to contact join the group
and what protocol modes/options must be supported to participate
as a group member. The public announcement mechanism is
implementation specific and not subject of this standard.
Other capabilities to be defined.
4.12 GSAKMP Node Local Management Interface
This sub-section describes those GSAKMP Node local management
interface requirements that are not specified elsewhere in the
GSAKMP IPsec mapping specification:
1. Configure a multicast application's ability to bind to a given
GSAKMP group.
2. Configure the Group Owner's public key certificate on a per GSAKMP
group basis.
3. Generate the Node Identity asymmetric cipher key pair, and create
the Node Identity public key certificate in cooperation with the
Group Owner management interface.
Gross Expires January, 2004 page 28
GSAKMP Application to the IP Security Architecture July, 2004
4. Provide the security policy controls for the subsystem that
generates Transport Endpoint Binding Attribute Certificates.
Other capabilities to be described.
4.13 Coordinating Security Policies Between Group Owners
A GSAKMP Node may simultaneously belong to multiple GSAKMP IPsec
groups that have independent Group Owner management systems. There
is a risk that uncoordinated SPI allocations by these Group Owners
could lead to two groups instructing a Node to use the same SPI.
More importantly, the GSAKMP IPsec policy token directed SPD updates
from two groups could conflict in their intent. Resolving such
conflicts requires manual intervention by the respective security
policy domains.
However, the GSAKMP IPsec mapping does provide the following tools
to diagnose or avoid such security policy conflicts:
- A single GSAKMP Group Owner management system SHOULD be granted
the exclusive administrative control of all GSAKMP groups that
share a common multicast destination IP address (or SSM channel).
- The GSAKMP IPsec policy token information model embodies the
concept of security policy rule priorities. The GSAKMP IPsec Group
Owner management interface SHOULD provide the ability to assign a
GSAKMP group's SPD rule priorities from a re-locatable numeric
range. When two group's policies conflict due to an overlap in
their rule priorities, one of the groups can be adjusted to have
the numeric range assigned to its security policies set to a lower
or higher precedence than the other group.
- The GSAKMP IPsec policy token advertises the SPI range for each
multicast channel. The receiver Nodes can compare that range
against the SPI ranges announced for all other GSAKMP groups that
it is a participant for that same multicast channel. If the Node
detects an overlap to a SPI range, it MUST log a local error, and
it MAY notify its GSAKMP Group Owners of the fault. The
notification mechanism is outside the scope of this standard.
5 GSAKMP IP Security Subsystem Profile
This section prescribes mandatory requirements on both the GSAKMP
IPsec implementation and its companion IP security subsystem.
Wherever feasible, these requirements align with the existing
Gross Expires January, 2004 page 29
GSAKMP Application to the IP Security Architecture July, 2004
requirements imposed by RFC2401-bis and IKE-v2. No attempt is made
by the GSAKMP IPsec application to achieve backward compatibility
with legacy RFC2401 IPsec subsystems. The GSAKMP IPsec application
generally avoids sub-setting RFC2401-bis, and it is an explicit goal
that the GSAKMP IPsec application does not preclude its
implementation in any of the major IP security architectures: native
host-based system, Bump-In-The-Stack (BITS), Bump-In-The-Wire
(BITW), or as a security gateway.
5.1 GSAKMP Requirements on the IP Security Subsystem
The primary GSAKMP IPsec requirement is a RFC2401-bis compliant IP
security system that supports the secure multicast option as defined
in section 4.1 [RFC2401-bis] and also section 2.1 of [RFC2406-bis].
A GSAKMP IPsec mapping implementation MUST support Encapsulating
Security Payload (ESP) [RFC2406-bis] and it MAY support
Authentication Header (AH) [RFC2402-bis].
RFC2401-bis permits an IP security subsystem to have only one SPD
per Node rather than one SPD per network interface (this is an
architectural revision from RFC2401). The GSAKMP IPsec policy token
requires that the IPsec subsystem MUST have only one SPD, as the
GSAKMP IPsec policy token multicast sets the SPD configuration
identically at all of the group's endpoints. Practical limits on the
policy token's message length prohibits encoding the configuration
for all of a group's individual network interfaces and their
respective SPD configurations. The single SPD per GSAKMP Node
encompasses the SPD-I, SPD-S, and the SPD-O. All of those
components, and also the Node's SAD, MUST be accessible for
configuration updates by the GSAKMP IPsec implementation
interpreting the GSAKMP IPsec policy token. Figure 1 shows the
control interface (C0) between GSAKMP and the IP security subsystem.
The mechanism that provides that SPD/SAD access is a local
implementation matter outside the scope of this standard.
Both the GSAKMP IPsec implementation and its underlying IPsec
subsystem MUST support logical expressions that combine the
following types of SPD traffic selectors as defined by RFC2401-bis
section 4.4 and the ASN.1 syntax declared in its Appendix A:
- Destination IP-v4 address range, both unicast and multicast
- Source IP-v4 address range
Gross Expires January, 2004 page 30
GSAKMP Application to the IP Security Architecture July, 2004
- Destination and source IP-v6 address range traffic selectors -
This requirement includes the GSAKMP Group Owner management
interface capability to configure skipping IP-v6 extension headers
for the Next Layer Protocol selector, as per RFC2401-bis section
4.4.2.
- Next Layer Protocol range,
- Transport protocol-dependent source port range and destination
port range selectors for UDP, TCP, SCTP, ICMP, and NORM.
- The "opaque" and "any" attributes for each of the above five
selectors.
- The SPD-outbound traffic selectors, using a symbolic "Name"
selector, can trigger a candidate group member's GSAKMP
registration with a GC/KS. See section 5.9 for additional details.
- The GSAKMP IPsec implementation and the SPD-outbound MUST support
the Populate From Packet (PFP) feature as required by RFC2401-bis
section 4.4.1.
This version of the GSAKMP IPsec mapping does not support
compression, although a future version may introduce support for
that feature. The GSAKMP IPsec implementation MAY support quality of
service using parallel group security associations, each group
security association having a separate datagram flow marked with a
DSCP. The algorithm that selects the GSA for a given DSCP marked
datagram is outside the scope of this specification.
Subsequent sections provide additional requirements and
clarifications with respect to GSAKMP interactions with the IP
security subsystem.
5.2 Authentication Header Group Security Associations
If the GSAKMP IPsec implementation does support AH, then the Group
Owner MUST assign AH group security association SPI that are unique
from those SPI that its assigns to its ESP group security
associations (i.e. ESP and AH share the same SPI pool).
In addition, a GSAKMP IPsec subsystem that supports AH MUST also
support SA bundles (i.e. the combination of AH and ESP in one
datagram).
Gross Expires January, 2004 page 31
GSAKMP Application to the IP Security Architecture July, 2004
5.3 Secure Multicast Application Service Models
The vast majority of secure multicast applications can be catalogued
by their service model and accompanying intra-group communication
patterns. Both the GSAKMP IPsec implementation and the IPsec
subsystem MUST be able to configure the SPD/SAD security policies to
match these dominant usage scenarios. The SPD/SAD policies MUST
include the ability to configure both Any-Source-Multicast groups
and Source-Specific-Multicast groups for each of these service
models. The GSAKMP management interface MAY include mechanisms to
configure the security policies for service models not identified by
this standard
5.3.1 Unidirectional Multicast Applications
Multi-media content delivery multicast applications without
congestion notification or retransmission error recovery are
inherently unidirectional. RFC2401-bis only defines bi-directional
unicast security associations (as per sections 4.4.1 and 5.1 with
respect to SA directionality). The GSAKMP IPsec mapping requires
that the IPsec subsystem MUST support unidirectional group security
associations. Applications that have only one group member
authorized to transmit can use this type of group security
association to enforce that group policy. In the inverse direction,
the GSA does not have a SAD entry, and the SPD configuration is
setup to discard unauthorized attempts to transmit to the group.
Although supported as a GSAKMP IPsec configuration, this multicast
application service model is NOT RECOMMENDED because it does not
have congestion control feedback capabilities.
The GSAKMP Group Owner management interface MUST have the ability to
setup a GSAKMP group having a unidirectional GSA security policy.
5.3.2 Bi-directional Reliable Multicast Applications
Some secure multicast applications are characterized as one speaker
to many listeners, but with inverse data flows required by a
reliable multicast transport protocol (e.g. NORM). In such
applications, the data flow from the speaker is multicast, and the
inverse flow from the group's listeners is unicast to the speaker.
Typically, the inverse data flows carry error repair requests and
congestion control status.
Gross Expires January, 2004 page 32
GSAKMP Application to the IP Security Architecture July, 2004
For such applications, the GSA SHOULD use IPsec anti-replay
protection service for the speaker's multicast data flow to the
group's listeners. In the inverse direction, the GSA anti-replay
protection MUST be disabled. The group listener's SPD entry for this
GSA MAY be configured to only allow a unicast transmission to the
speaker Node rather than a multicast transmission to the whole
group. If available, a source authentication mechanism (e.g. ESP
digital signature) SHOULD be used to authenticate the listener
Node's transmission to the speaker.
The GSAKMP Group Owner management interface MUST have the ability to
setup a GSAKMP group having a bi-directional GSA security policy.
5.3.3 Any-To-Any Multicast Applications
Another family of secure multicast applications exhibit a "many to
many" communications pattern. A representative example of such an
application is a videoconference combined with an electronic
whiteboard.
For such applications, all (or a subset) of the group's endpoints
are authorized multicast speakers. The group SHOULD share one GSA
for all of its speakers. The GSA SHOULD NOT use IPsec anti-replay
protection service for the speaker's multicast data flow to the
group's listeners.
The GSAKMP Group Owner management interface MUST have the ability to
setup a GSAKMP group having an Any-To-Any Multicast GSA security
policy.
5.4 Co-Existence of Multiple Key Management Protocols
Often, GSAKMP will be introduced to an existent IPsec subsystem as a
companion key management protocol to IKE-v2 [IKE-v2]. A fundamental
GSAKMP IP Security subsystem requirement is that both GSAKMP and
IKE-v2 can simultaneously share access to a common Security Policy
Database and Security Association Database. The mechanisms that
provide mutually exclusive access to the common SPD/SAD data
structures are a local matter. This includes the SPD-outbound cache
and the SPD-inbound cache. However, implementers should note that
IKE-v2 SPI allocation is entirely independent from GSAKMP SPI
allocation because group security associations are qualified by a
destination multicast IP address and may optionally have a source IP
address qualifier. See [RFC2406-bis] section 2.1 for further
explanation.
Gross Expires January, 2004 page 33
GSAKMP Application to the IP Security Architecture July, 2004
The Peer Authorization Database does require explicit coordination
between GSAKMP and IKE-v2. Section 5.8 describes these interactions.
This document discusses the coordination of multiple GSAKMP group
owner and endpoint local management systems in section 4.11.
5.5 ESP GSA Properties
At the time of this writing, IPsec RFCs specify the support of the
following transforms and algorithms for use with AH and ESP: NULL
encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96. However,
"Cryptographic Algorithm Implementation Requirements For ESP And AH"
[CRYPTREQ] contains the current set of mandatory to implement
algorithms for ESP and AH. It also specifies algorithms that should
be implemented because they are likely to be promoted to mandatory
at some future time. GSAKMP IPsec Nodes SHOULD conform to the
requirements in [CRYPTREQ]. All GSAKMP IPsec subsystem
implementations MUST support both sending and receiving for the
following ESP GSA properties:
- Triple-DES encryption in CBC mode with an 168-bit key length
[RFC2451] [RFC2406-bis]. The 3DES-CBC encryption algorithm does
not suffer from the same security issues as DES-CBC, and the 3DES-
CBC algorithm within ESP MUST be supported to ensure
interoperability.
- The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be
supported within ESP. Security issues related to the use of DES
are discussed in [DESDIFF], [DESINT], [DESCRACK]. DES-CBC is
still listed as required by the existing IPsec RFCs, but updates
to these RFCs will be published soon. DES provides 56 bits of
protection, which is no longer considered sufficient.
- Group source authentication is mandatory, wherein the ESP
authenticator uses HMAC-SHA1-MAC96 [RFC2404]. An implementation
MAY also support the use of the HMAC-MD5-96 algorithm [RFC-2403]
within AH and ESP.
- Both transport and tunnel mode, as required by RFC2401-bis section
4.4.3. See section 5.10 for additional GSA tunnel mode
specifications.
- Anti-replay protection, configurable to use either sixty-four bit
or thirty two bit ESP sequence numbers
Gross Expires January, 2004 page 34
GSAKMP Application to the IP Security Architecture July, 2004
- Security association lifetime hard limits for both kilo-bytes
processed by the cryptographic transform and its lifetime duration
measured in units of seconds.
- Security association lifetime soft limits of both kilo-bytes
processed by the cryptographic transform and its lifetime duration
measured in units of seconds. The interpretation of SA soft
lifetime expiration is implementation dependent. However, it is
usually used to signal the GSAKMP subsystem that it should
proactively initiate re-registration with the group because one or
more Re-Key Event message(s) have failed to arrive in time.
- Sequence counter overflow - A configurable flag indicating whether
to log an audit message if the SA sequence number overflows (as
per [RFC2401-bis] section 4.4.3).
- Path MTU - The associated IPsec SA fragmentation policy MUST be
compliant to RFC2401-bis. The GSAKMP IPsec management interface
MUST provide a configuration capability to set the path MTU on a
per GSAKMP multicast speaker basis.
- UDP encapsulation of ESP [UDPESP].
In addition, GSAKMP IP Security implementations SHOULD support the
following additional ESP algorithms and modes:
- AES encryption in CBC mode with a 128-bit key length [RFC3602].
- AES combined encryption and authentication using Counter with CBC-
MAC96 (CCM) mode [AESCCM] with a 128-bit key length.
The GSAKMP Group Owner management interface MUST have the ability to
set a group's GSA policy to use null ESP encryption or null
authentication. All GSAKMP IPsec endpoints MUST support the NULL
encryption algorithm [RFC-2410] and the NULL authentication
algorithm [RFC-2406]. However, while authentication and encryption
can each be NULL, they MUST NOT both be NULL. The NULL encryption
algorithm is also useful for debugging.
5.6 Concurrent GSA Life Spans and Rollover
During a GSAKMP group's lifetime, multiple group security
associations can exist concurrently. This occurs principally due to
two reasons:
Gross Expires January, 2004 page 35
GSAKMP Application to the IP Security Architecture July, 2004
- There are multiple Group Speakers authorized in the group, each
with its own GSA that maintains anti-replay state. A group that
does not rely on IP Security anti-replay services can share one
GSA for all of its Group Speakers.
- The life span of a Group Speaker's two (or more) GSA are allowed
to overlap in time, so that there is continuity in the multicast
data stream across group re-key events. This capability is
referred to as "re-key rollover continuity".
This specification requires that a GSAKMP IPsec implementation MUST
support at least two concurrent GSA per Group Speaker to facilitate
multicast data stream re-key rollover continuity. Each SAM multicast
sent by a Group Speaker signals the start of a new Group Speaker
time epoch, with each such epoch having an associated GSA. The group
membership interacts with these GSA as follows:
- As a precursor to the Group Speaker beginning its re-key rollover
continuity processing, the GC/KS periodically multicasts a Re-Key
Event (RKE) message to the group. The RKE multicast contains a
revised GSAKMP IPsec policy token, group membership management
directives (e.g. LKH), and a new Group Traffic Protection Key
(GTEK).
- After successfully processing the RKE multicast, the Group Speaker
creates its new "leading edge" Group Security Association by
multicasting a SAM message to the group. The SAM multicast
configures the group's SPD/SAD with the leading edge GSA state
information. The leading edge GSA allocates a new Security
Parameter Index and it is keyed by the GTEK distributed by the
most recent RKE multicast. For a short period after multicasting
the SAM, a Group Speaker does not transmit data using the leading
edge GSA. However, all of the Group Receiver endpoints prepare to
use this GSA by installing the SAM directed changes to their
respective SPD/SAD.
- After waiting a sufficiently long enough period such that all of
the Group Receiver endpoints have processed the SAM multicast, the
Group Speaker begins to transmit using the leading edge GSA with
its data encrypted by the new GTEK. Only authorized Group Members
can decrypt these GSA multicast transmissions. The time delay that
a Group Speaker waits before starting its first leading edge GSA
transmission is a GSAKMP IPsec policy token parameter. This value
SHOULD be configurable at the Group Owner management interface on
a per GSAKMP group basis.
Gross Expires January, 2004 page 36
GSAKMP Application to the IP Security Architecture July, 2004
- The Group Speaker's "trailing edge" GSA is the oldest group
security association in use by the group for that speaker. All
authorized Group Receiver endpoints can receive and decrypt data
for this GSA, but the Group Speaker does not transmit new data
using the "trailing edge" GSA after it has transitioned to the
"leading edge GSA".
This rollover strategy allows the group to drain its in transit
datagrams from the network while transitioning to the leading edge
GSA. Staggering the roles of each respective GSA as described above
improves the group's synchronization even when there are high
network propagation delays. Note that due to group membership joins
and leaves, each Group Speaker time epoch may have a different group
membership set. It is a group policy decision whether the re-key
events provide forward and backward secrecy at these re-key event
transitions between epochs. This group policy is declared in the
policy token, and that policy is enforced by its re-key protocol's
keying material and algorithm (e.g. Logical Key Hierarchy).
Implementations MAY offer a Group Owner management interface option
to enable/disable re-key rollover continuity for a particular group,
but by default it MUST be enabled.
5.7 Multiple Group Speakers and Source Authentication
A GSAKMP IPsec implementation MUST support at least one Group
Speaker per GSAKMP group and it MAY support more than one Group
Speaker per group. This requirement is in addition to the
requirement to support a GC/KS as a Group Speaker along with its
attendant Re-Key GSA.
The GSAKMP IPsec policy token specifies the Group Speaker
authorization pattern matching rules, authorizing one or more group
endpoints to become Group Speakers. In the Any-Source Multicast
(ASM) usage model, all of the group members are authorized to speak
to the group.
When the group's GSAKMP IPsec policy token requires IP Security
anti-replay protection service, then there MUST be only one Group
Speaker authorized per GSA per time epoch. In other words, when
anti-replay service is enabled for a group, then there MUST be as
many GSA allocated and operating per group time epoch as there are
Group Speakers. Each such GSA will have its own set of SPD policies,
anti-replay state, and MAY have its own multicast destination IP
address. All of these GSA share a common group membership set.
GSAKMP IPsec implementations MUST support IPsec anti-replay services
Gross Expires January, 2004 page 37
GSAKMP Application to the IP Security Architecture July, 2004
for at least one Group Speaker. Although this requirement may not
scale to larger groups, the GSAKMP IPsec management interface SHOULD
support a configurable number of Group Speakers per group using the
anti-replay service. The RECOMMENDED minimum number of such Group
Speakers is 8.
By default, both the SPD-inbound and SPD-outbound traffic selectors
MUST be configured with security policy actions that discard
unauthorized multicast transmission attempts. This inhibits the
spoofing of a peer group member's transmissions by a rogue group
member. However, group transmissions that have stronger source
authentication policy requirements (e.g. messages having group
control, economic, or legal implications) SHOULD use per packet
multicast source authentication techniques.
5.8 GSAKMP IPsec Interactions with the PAD
The Peer Authorization Database (PAD) MUST provide a management
interface capability that allows an administrator to enforce that
the scope of a GSAKMP group's policy token specified SPD/SAD
modifications are restricted to only those traffic data flows that
belong to that group. This authorization MUST be configurable at
GSAKMP group granularity. In the inverse direction, the PAD
management interface MUST provide a mechanism(s) to enforce that
IKE-v2 security associations do not negotiate traffic selectors that
conflict or override GSAKMP group policies. An implementation SHOULD
offer PAD configuration capabilities that authorize GSAKMP policy
token to set security policy for all aspects of an endpoint's
SPD/SAD configuration, not just its GSAKMP group security
associations. This capability allows the group's policy to inhibit
the creation of back channels that might otherwise leak confidential
group application data.
The PAD also defines the trust anchor public key certificates for
each GSAKMP group. See section 9.5.
5.9 Security Policy Database Symbolic Name Selectors
The RFC2401-bis section 4.4.2 describes SPD symbolic name selectors
and several examples of their usage. GSAKMP IPsec implementations
MUST support SPD symbolic name selectors for the two cases that
depend on this feature: the GC/KS response to a Request-To-Join
(RTJ), and triggering a GSAKMP registration attempt in response to
starting a multicast application (e.g. a socket bind() system call).
Gross Expires January, 2004 page 38
GSAKMP Application to the IP Security Architecture July, 2004
When a GC/KS receives a GSAKMP RTJ message from a candidate group
member, the GC/KS looks up the TEBAC Certificate payload's Issuer
identification field's value in the SPD. If one of the SPD symbolic
name selector entries matches that value, then the system is locally
authorized to act as a GC/KS for that candidate group member.
However, the GSAKMP IPsec policy token currently in the possession
of the GC/KS ultimately decides whether the GC/KS allows that
candidate group member to join the group, or denies the join
request. The GSAKMP IPsec local management interface MUST provide
the GC/KS configuration tools that create each GSAKMP group's SPD
symbolic name selector(s). All GSAKMP IPsec implementations MUST
have the latent capability to be configured as a S-GC/KS, although
local policy may not enable it.
In a multi-user native host-based GSAKMP IPsec system, a SPD
symbolic name selector matching an application endpoint's
authenticated identity, (optionally in combination with other
traffic selectors), MUST initiate a request to join a GSAKMP group.
In this context, the operating system is trusted to have previously
authenticated the user's identity and created his/her TEBAC
credentials in compliance with the group's application endpoint
authentication policy. For example, the matching SPD name selector
may trigger an AAA application that generates the TEBAC credentials.
The GSAKMP IPsec subsystem transparently proxies that candidate
Group Member's signature for the GSAKMP messages that it sends in
the registration SA exchange.
Alternatively, a GSAKMP IPsec native host-based implementation MAY
define a mechanism, such as an application program interface, that
facilitates the application endpoint's direct signature of its
GSAKMP messages without TEBAC signature delegation. This
specification does not standardize this mechanism.
For those GSAKMP IPsec implementations within a BITS, BITW, or
security gateway, there MUST be a mechanism to trigger the GSAKMP
registration protocol exchange. For example, the GSAKMP IPsec
subsystem may interact with an application layer protocol gateway
service that initiates the group membership registrations. This
includes the GSAKMP IPsec subsystem acquiring the appropriate TEBAC.
However, that mechanism is a local implementation issue. The
mechanism may not necessarily use a SPD symbolic name selector, and
the mechanism is not standardized by this specification.
Gross Expires January, 2004 page 39
GSAKMP Application to the IP Security Architecture July, 2004
5.10 Tunnel Mode Group Security Associations
GSAKMP IPsec implementations MUST support IPsec tunnel mode group
security associations as prescribed by [RFC2401-bis] section 5.1.2.
One anticipated application for this capability is a set of
multicast-capable IPsec gateways at the border between an
untrustworthy public Internet and a group of one or more trusted
private networks. The IPsec GSA tunnel's outer IP header delivers
the encrypted multicast datagram across the public Internet to each
of the group's IPsec gateways. Once that payload is de-capsulated at
the GSA destination tunnel endpoint and it is decrypted, then the
multicast IPsec gateway multicasts the inner IP header and its
plain-text payload to the group's endpoints within the gateway's
respective private network.
This specification requires that a GSAKMP IPsec implementation also
MUST support a Group Owner management interface that facilitates the
configuration of all of a RFC2401-bis tunnel mode SA attributes:
- All of the relevant tunnel source endpoint's outer IP header
attributes.
- For IP-v4 tunnels, the Do Not Fragment flag copy policy
- DSCP _ copy from inner IP header to outer IP header or else GSAKMP
IPsec assigns the outer IP header's DSCP to a value fixed by the
group's policy.
- For IP-v6 tunnels, the flow label copy or set policy
5.11 Multicast Packet Distributor Policy Action
This section introduces the "Multicast Packet Distributor", a
security policy building block that takes a packet as its input,
replicates the packet, and distributes the copies to two or more
downstream policy action components. The formal definition is
deferred to [IPSECPT].
The Group Owner management interface MAY provide the configuration
tools needed to encode policy tokens containing Multicast Packet
Distributor policy actions. All GSAKMP IPsec implementations MUST be
able to interpret any correctly encoded policy token containing a
Multicast Packet Distributor, and correctly enforce its policies.
Gross Expires January, 2004 page 40
GSAKMP Application to the IP Security Architecture July, 2004
5.11.1 Basic and Composite GSAKMP Groups
In the trivial case, there is a 1:1 relationship between a GSAKMP
group identifier, a multicast application, and a multicast IP
address. In other words, a basic GSAKMP group has only one multicast
application destination port number, and it has only one multicast
IP address. A GSAKMP Group Owner management system MUST be able to
set up a GSAKMP group having this basic configuration.
However, the GSAKMP IPsec architectural model does not preclude the
creation of a GSAKMP "composite group" and SPD policy that
aggregates multiple basic GSAKMP sub-groups. In this service model,
the multicast application multicasts one message payload to all of
the group's endpoints, and the GSAKMP IPsec subsystem transparently
replicates that message and distributes a copy to each of the sub-
groups. The goal is to accommodate GSAKMP group endpoint populations
that have heterogeneous capabilities or attributes. Some examples
where a composite group could be applied include:
- A GSAKMP group straddling both IP-v4 and IP-v6 endpoints. For a
group spanning IP-v4 and IP-v6, the Group Speaker endpoint's Node
must be dual stack capable.
- A single GSAKMP group using a Reliable Multicast Transport
protocol (RTMP) that has a heterogeneous deployment of error
recovery algorithms (e.g. Forward Error Correction codes) at its
endpoint population. Each RMTP version is configured as a sub-
group at a distinct multicast destination IP address. In this
case, the application's payload is replicated within the speaker
Node before being distributed to each RMTP version-specific
subsystem. The Group Speaker endpoint's Node must implement all of
the RMTP sub-group versions.
- There are multiple multicast routing domains supporting the GSAKMP
group, each routing domain imposing its own policy defined
multicast IP address. The GSAKMP IPsec must alter the multicast
destination IP address for each copy of the multicast packet
before it is sent to its respective routing domain.
- A multicast application wherein the GSAKMP group is the union of
multiple source-specific IP multicast groups. For example, a
multi-homed Group Speaker might require this configuration.
In principal, each of the above examples could be decomposed into
multiple independent basic GSAKMP groups. However, that incurs a
Gross Expires January, 2004 page 41
GSAKMP Application to the IP Security Architecture July, 2004
commensurate increase in the multicast application's overhead to
discover, join, and manage each of those groups. A preferable
solution is for the multicast application to join one GSAKMP group,
and have the GC/KS bundle the multiple basic group SPD traffic
selector rules into a single policy token configuration operation.
This type of SPD configuration encodes the GSAKMP "composite group"
security policy. A composite group has the following properties:
- The composite group membership is the union of two or more non-
overlapping basic sub-group memberships formed by the sub-group's
Group Receiver endpoints. All of the sub-groups share the
composite group's GTEK and algorithm.
- When a Group Receiver endpoint joins a composite group, it also
selects its membership in one of the basic sub-groups. The sub-
group selection can be implicit (i.e. pre-configured at the GC/KS)
or explicitly signaled in the group member's RTJ sent to the
GC/KS. The signaling mechanism MAY be the TEBAC payload, or it MAY
be an implementation defined mechanism not standardized by this
version of the GSAKMP IPsec mapping.
- The multicast application Group Speaker endpoint sends a single
message to the composite group and it is received once at each
endpoint within a sub-group. The Group Speaker's Node is
responsible for transparently replicating that message and sending
a copy to each sub-group within the composite group. When the
Group Speaker endpoint joins a composite group, it implicitly
joins all of the basic sub-groups as a speaker.
- If the Multicast Packet Distributor policy action occurs before
encryption, then there is a GSA per sub-group (assuming anti-
replay service is enabled).
- If the Multicast Packet Distributor policy action occurs after
encryption, then there is one GSA for the composite group.
- There SHOULD be a Subordinate-GC/KS per GSAKMP sub-group.
5.11.2 Transmitter Multicast Packet Distributor
The GSAKMP IPsec policy token grammar (see [IPSECPT]) has the
expressive power to describe and manage composite group security
policies. The GSAKMP IPsec policy action Multicast Packet
Distributor can be inserted as one action in the sequenced list that
constitutes a compound policy action. The Multicast Packet
Gross Expires January, 2004 page 42
GSAKMP Application to the IP Security Architecture July, 2004
Distributor building block distributes each application message
transmission to the composite group's sub-groups. The group's policy
decides whether the distribution occurs before or after the
message's GSA encryption policy action.
5.11.3 Receiver Multicast Packet Distributor
At a receiving Node, the Receiver Multicast Packet Distributor is
the decryption and distribution control point for the one or more
authorized Group Receiver endpoints co-residing on that Node. This
has the benefit that the Node receives one encrypted multicast
datagram regardless of the number of such endpoints, decrypts its
ESP payload once, and securely distributes that plain-text payload
to each of the authorized application endpoints within that Node.
The mechanism through which the Node achieves that secure
distribution is a local implementation matter.
Note that after the decryption step but before the plain-text
distribution, the IP security subsystem compares the datagram's
attributes against the SPD-inbound traffic selectors, and verifies
that the datagram conforms to the GSA's security policy. If the
verification succeeds, then the GSA forwards the datagram to the
Receiver Multicast Packet Distributor. If a multicast application
destination port has multiple Group Speaker GSA in a given time
epoch, all of those GSA forward their datagrams to the same Receiver
Multicast Packet Distributor.
Internal to the Node, the Receiver Multicast Packet Distributor is
the single control state shared between one or more authorized Group
Receiver endpoints for a group time epoch. There is a Receiver
Multicast Packet Distributor instance per GSAKMP group per time
epoch that has authorized Group Receiver endpoints as members within
a Node.
5.12 UDP Encapsulated ESP GSA
To be defined.
6 GSAKMP Interactions with NAT and Mobility
With the advent of NAT and mobile Nodes, GSAKMP IPsec multicast
applications must overcome several architectural barriers to their
successful deployment. This section surveys those problems, and
section 7 specifies a GSAKMP protocol extension as their solution.
Gross Expires January, 2004 page 43
GSAKMP Application to the IP Security Architecture July, 2004
6.1 SPD Losses Synchronization with Internet Layer's State
The most prominent problem facing GSAKMP IPsec is that the GSAKMP
IPsec policy token can inadvertently configure the group's SPD
traffic selectors with unreliable transient IP addresses. The IP
addresses are transient because of either Node mobility or Network
Address Translation (NAT), both of which can unilaterally change a
multicast speaker's source IP address without signaling GSAKMP. The
absence of a SPD synchronization mechanism can cause the group's
data traffic to be discarded rather than processed correctly.
6.1.1 Mobile Multicast Care-Of Address Route Optimization
Both Mobile IP-v4 [RFC3344] and Mobile IP-v6 [MIPV6] provide
transparent unicast communications to a mobile Node. However,
comparable support for secure multicast mobility management is not
specified by these standards. The goal is the ability to maintain an
end-to-end transport mode group SA between a Group Speaker mobile
node that has a volatile care-of-address and a Group Receiver
membership that also may have mobile endpoints. In particular, there
is no secure mechanism for route optimization of the triangular
multicast path between the correspondent Group Receiver Nodes, the
home agent, and the mobile Node. Any proposed solution must be
secure against hostile re-direct and flooding attacks.
6.1.2 NAT Translation Mappings Are Not Predictable
The following spontaneous NAT behaviors adversely impact source-
specific secure multicast groups. When a NAT gateway is on the path
between a Group Speaker endpoint residing behind a NAT and a public
IP-v4 multicast Group Receiver, the NAT gateway alters the private
source address to a public IP-v4 address. This translation must be
coordinated with every Group Receiver's inbound Security Policy
Database (SPD) multicast entries that uses that source address as a
traffic selector. One might mistakenly assume that the GC/KS can set
up the GSAKMP endpoints with a SPD entry that anticipates the
value(s) that the NAT translates the packet's source address.
However, there are known cases where this address translation can
spontaneously change without warning:
- NAT gateways may re-boot and lose their address translation state
information.
Gross Expires January, 2004 page 44
GSAKMP Application to the IP Security Architecture July, 2004
- The NAT gateway may de-allocate its address translation state
after an inactivity timer expires. The address translation used by
the NAT gateway after the resumption of data flow may differ than
that known to the SPD selectors at the GSAKMP endpoints.
- The GC/KS may not have global consistent knowledge of a GSAKMP
endpoint's current public and private address mappings due to
network errors or race conditions. For example, an endpoint's
address may change due to a DHCP assigned address lease
expiration.
- Alternate paths may exist between a given pair of GSAKMP
endpoints. If there are parallel NAT gateways along those paths,
then the address translation state information at each NAT gateway
may produce different translations on a per packet basis.
The consequence of this problem is that the GC/KS can not be pre-
configured with NAT mappings, as the SPD at the group's endpoints
will lose synchronization as soon as a NAT mapping changes due to
any of the above events. In the worst case, group endpoints in
different sections of the Internet will see different NAT mappings,
because the multicast packet traversed multiple NAT gateways.
6.2 Secondary Problems Created by NAT Traversal
6.2.1 SSM Routing Dependency on Source IP Address
Source-Specific Multicast (SSM) routing depends on a multicast
packet's source IP address and multicast destination IP address to
make a correct forwarding decision. However, a NAT gateway alters
that packet's source IP address as its passes from a private network
into the public Internet. Mobility changes a Node's point of
attachment to the Internet, and this also will change the packet's
source IP address. Regardless of why it happened, this alteration in
the source IP address makes it infeasible for transit multicast
routers in the public Internet to know which SSM speaker originated
the multicast packet, which in turn selects the correct multicast
forwarding policy.
6.2.2 ESP Cloaks Its Payloads from NAT Gateway
When traversing NAT, application layer protocols that contain IP-v4
addresses in their payload need the intervention of an Application
Layer Gateway (ALG) that understands that application layer protocol
[RFC3027] [RFC3235]. The ALG massages the payload's private IP-v4
Gross Expires January, 2004 page 45
GSAKMP Application to the IP Security Architecture July, 2004
addresses into equivalent public IP-v4 addresses. However, when
encrypted by end-to-end ESP, such payloads are opaque to application
layer gateways.
When multiple Group Speaker endpoints reside behind a NAT with a
single public IP-v4 address, the NAT gateway can not do UDP or TCP
protocol translation (i.e. NAPT) because the ESP encryption conceals
the transport layer protocol headers. The use of UDP encapsulated
ESP [UDPESP] avoids this problem. However, this capability must be
configured at the GC/KS as a group policy, and it must be supported
in unison by all of the GSAKMP endpoints within the group, even
those that reside in the public Internet.
6.2.3 UDP Checksum Dependency on Source IP Address
A GSAKMP IPsec multicast application that uses UDP within an ESP
payload will encounter NAT induced problems. The original IP-v4
source address is an input parameter into a receiver's UDP pseudo-
header checksum verification, yet that value is lost after the IP
header's address translation by a transit NAT gateway. The UDP
header checksum is opaque within the encrypted ESP payload.
Consequently, the checksum can not be manipulated by the transit NAT
gateways. UDP checksum verification needs a mechanism that recovers
the original source IP-4 address at the Group Receiver endpoints.
In a transport mode multicast application GSA, the UDP checksum
operation requires the origin endpoint's IP address to complete
successfully. In IKE-v2 [IKE-v2], this information is exchanged
between the endpoints by a NAT-OA payload (NAT original address).
See also reference [IPSECNAT]. A comparable facility must be exist
in a GSAKMP payload that defines the multicast application GSA
attributes for each Group Speaker endpoint.
6.2.4 Can Not Use AH with NAT Gateway
The presence of a NAT gateway makes it impossible to use an
Authentication Header, keyed by a group-wide key, to protect the
integrity of the IP header for transmissions between members of the
cryptographic group.
6.3 Avoidance of NAT Using an IP-v6 Over IP-v4 Network
A straight forward and standards-based architecture that effectively
avoids the GSAKMP interaction with NAT gateways is the IP-v6 over
IP-v4 transition mechanism [RFC2529]. In IP-v6 over IP-v4 (a.k.a.
Gross Expires January, 2004 page 46
GSAKMP Application to the IP Security Architecture July, 2004
"6over4"), the underlying IP-v4 network is treated as a virtual
multicast-capable Local Area Network. The IP-v6 traffic tunnels over
that IP-v4 virtual link layer.
Applying GSAKMP in a 6over4 architecture leverages the fact that an
administrative domain deploying GSAKMP would already be planning to
deploy IP-v4 multicast router(s). The GSAKMP group's IP-v6 multicast
routing can execute in parallel to IP-v4 multicast routing on that
same physical router infrastructure. In particular, the NAT gateways
at administrative domain public/private boundaries are replaced by
IP-v6 multicast routers operating with 6over4 mode enabled on their
network interfaces.
Within the GSAKMP protocol, all references to IP addresses are IP-v6
addresses for all security association endpoints and these addresses
do not change over the group's lifetime. This yields a substantial
reduction in complexity and error cases over the NAT-based
approaches. This reduction in complexity can translate into better
security.
Reliable scalable GSAKMP 6over4 deployment is far more practical
than GSAKMP/NAT with IP-v4. In particular, new GSAKMP multicast
applications SHOULD prefer GSAKMP IP-v6 native mode. However, GSAKMP
supports either choice. The following factors may weigh against the
decision to deploy GSAKMP 6over4:
- A drawback of the GSAKMP 6over4 approach is that the secure
multicast application must be (re-)written to an IP-v6 multicast
socket API or equivalent, and it must interact with the Multicast
Listener Discovery (MLD) API [RFC3590] [RFC3678] rather than IGMP.
In addition, the application layer protocol itself must embed
references to IP-v6 addresses rather than IP-v4 addresses within
its payloads. For new applications, this may not be of
consequence; it usually only becomes an issue if the application
and its protocol has an embedded base.
- An embedded base of GSAKMP IP-v4 multicast applications that are
only available in binary form will not be able to migrate to these
transitional IP-v6 mechanisms.
- The secondary drawbacks of GSAKMP 6over4 are that the IP hosts
must be upgraded to dual-stack, the attendant overlay IP-v6
multicast network operational costs, and the difficulty of
deploying commercial wide-area IP-v6 multicast services.
Gross Expires January, 2004 page 47
GSAKMP Application to the IP Security Architecture July, 2004
6.4 GSAKMP Multi-Realm IP-v4 NAT Architecture
In a multi-realm group, GSAKMP security association endpoints may
straddle any combination of IP-v4 public addresses and private
addresses [RFC1918]. In such cases, transport layer endpoint
identifiers when resolved to their underlying private or public IP-
v4 addresses entangle the GSAKMP protocol with NAT gateway
behaviors. The NAT translation of IP-v4 header addresses impacts the
GSAKMP registration SA, the GSAKMP re-key GSA, and the multicast
application GSA.
This section overviews the GSAKMP mechanisms that partially mitigate
the inherent complexity spawned by IP-v4 NAT and Network Address
Protocol Translation (NAPT) traversal. However, the attendant Group
Owner configuration procedures are labor-intensive, prone to
configuration mismatch errors between the GC/KS and NAT gateways,
and they do not scale well to large groups. Given the large number
of documented NAT problems and its erosion of end-to-end security,
new GSAKMP applications and deployments SHOULD strongly prefer the
use of IP-v6. Section 6.3 offers IP-v4 to IP-v6 transitional
guidance in support of that objective.
6.4.1 GSAKMP IP-v4 NAT Architectural Assumptions
To make the multi-realm GSAKMP IP-v4 NAT interaction problem
tractable to a solution, this specification makes the following
simplifying assumptions:
- The secure multicast group destination address is a statically
allocated public IP-v4 multicast address known to all GSAKMP
endpoints.
- Wherever they are present in the GSAKMP protocol, GSAKMP endpoint
addresses are expressed as permanent IP-v6 "6to4" addresses
[RFC3056] to assure that the GSAKMP endpoints that refer to hosts
assigned private IP-v4 addresses are globally unique. In this
context, a "permanent" 6to4 address means that the address is
constant for the group's lifetime.
- Each private IP-v4 address space has one or more NAT gateways
directly connected to the IP-v4 public Internet, and a packet does
not have to traverse multiple private networks to reach the public
Internet. This can be thought of as a "spoke and hub"
configuration wherein the public Internet is the hub.
Gross Expires January, 2004 page 48
GSAKMP Application to the IP Security Architecture July, 2004
- A GC/KS may reside within one of the private networks, but it
also MUST have a permanent public IP-v4 address on at least one of
its network interfaces. This requirement applies to both the
Primary-GC/KS and all of the group's Subordinate-GC/KS.
- GSAKMP group security associations are end-to-end transport mode.
However, since the S-GC/KS are constrained to straddle a
public/private network boundary, they effectively terminate the
GSA at a combined NAT/security gateway [RFC2709].
- The GC/KS domain name RR record should point to that public IP-v4
address, and it should be protected by DNS-SEC.
- Each of an administrative domain's NAT gateways are explicitly
configured with static private/public address translation mappings
for the GC/KS's GSAKMP re-key multicast ESP protected UDP packets
inbound from the public Internet [RFC2588].
- The NAT gateways/firewalls are explicitly configured with
stateless filter rules that simply pass through without any
address translation the group's inbound multicast application
packets arriving from the public Internet. The NAT gateway does
not translate the multicast application packet's public multicast
IP destination address into a private IP multicast address.
- In the outbound direction, NAT gateways generally translate the
multicast application packet's private source IP address into a
dynamically selected public IP address. Exceptions to this policy
for source specific multicast are noted in subsequent sections.
- Within each administrative domain, a multicast routing protocol
domain routes packets based on the group's destination multicast
public IP-v4 address. The multicast routers will distribute the
group's packets to all of the group's Group Receiver endpoints
residing in that administrative domain.
- The border routers of each of the administrative domains spanned
by the group do cross-realm multicast routing and distribution on
behalf of the group. The IP-v4 multicast routers that exchange
reachability information regarding the group across trust
boundaries authenticate that information.
Gross Expires January, 2004 page 49
GSAKMP Application to the IP Security Architecture July, 2004
"A" Admin . ISP Admin . "B" Admin
Domain . Domain . Domain
. .
+---------------.--------------.-------------------+
| . . |
| P U B L I C . I P - v 4 . I N T E R N E T |
| . . |
+------/\-------.-----A-----A--.----/\--------/\---+
|| public. | | . || public ||
|| IP-v4 . | | . || IP-v4 ||
+------\/------+. | | .+---\/---+ +--\/---+
|Grp.Z |NAT "A"|. | | .|Group Z | |NAT "B"|
|S-GCKS|gateway|. | | .|P-GC/KS | |gateway|
+---A--+---A---+. | | .+---A----+ +--A----+
| | .registratn | . | |
regist. SA| . SA | . regist. SA |
| | . | | . | |
+-V-+ | . +-V-+ | . +-V-+ |
|GM1| | . |GM2| | . |GM3| |
+-A-+ | . +-A-+ | . +-A-+ |
| | . | | . | |
Group data SA . Group data SA. Group data SA
rekey SA . rekey SA . and rekey SA
| | . | | . | |
+-V------V--+ . +---V-----V-+.+---V---------V-+
| Group "Z" | . | Group "Z" |.| Group "Z" |
| multicast | . | multicast |.| multicast |
| routing | . | routing |.| routing |
| domain | . | domain |.| domain |
+-----------+ . +-----------+.+---------------+
. .
Figure 2 Representative GSAKMP/NAT architecture
6.4.2 Representative GSAKMP Multi-Realm Configuration
Figure 2 illustrates a representative group "Z" wherein a GSAKMP
group security association spans two private IP-v4 networks and the
public IP-v4 Internet. The Group "Z" GC/KS has two network
interfaces, one attached to the public Internet and the other
interface attached to the administrative domain "B" private network.
The group member GM1 resides within the administrative domain "A"
private network. It communicates with the group Z Group Speaker
endpoint(s) through the administrative domain "A" NAT gateway. When
Gross Expires January, 2004 page 50
GSAKMP Application to the IP Security Architecture July, 2004
GM1 multicasts application SA traffic to the group Z public
multicast address, the Group Z peer members (i.e. GM2, and GM3)
receive that multicast with the source address translated by NAT
gateway "A" processing. In the inverse direction, the administrative
domain "A" NAT gateway/firewall must be configured to allow Group Z
multicast application GSA traffic to enter the private network "A"
from the public Internet (e.g. a multicast originating from GM3).
The group member GM3 resides within the administrative domain "B"
private network. Its interactions with Group Z are very similar to
those discussed for member GM1. It uses private addresses when
communicating with the P-GC/KS, as it is in private network "B".
The group member GM2 is in a public Internet administrative domain
operated by an ISP. It communicates with the P-GC/KS using public
IP-v4 addresses without passage through a NAT gateway. When GM2
multicasts application SA traffic to the group Z public multicast
address, the Group Z peer members behind NAT gateways receive that
multicast with the source address unchanged by NAT processing.
Each administrative domain operates an IP-v4 multicast routing
domain instance. The multicast routers distribute both GSAKMP RKE
messages and multicast application GSA data traffic. The multicast
routing for group "Z" peers between these three multicast routing
domains.
6.4.3 Registration Security Association NAT Traversal
The GSAKMP registration protocol's unicast messages are exchanged
between a GC/KS in the public IP-v4 Internet and a candidate Group
Member that may be in a private network.
A group member sends a registration SA GSAKMP message to the GC/KS
public IP-v4 address and the GSAKMP reserved port number. The group
member assigns a unique GSAKMP UDP source port number for each
GSAKMP registration SA that it participates in. The group member
SHOULD send the GSAKMP UDP packet without a checksum to avoid NAT
alterations to that field. The UDP packet's transmission error
detection depends on the GSAKMP Signature payload. A NAT gateway on
the path leading to the GC/KS translates the private source IP
address and source UDP port number into a public address and a
temporary UDP port number (assuming NAPT), then forwards the packet
to the GC/KS. The NAT gateway creates state information for that
public/private address mapping so it can do the inverse translation
on the GSAKMP messages sent from the GC/KS to that group member.
Gross Expires January, 2004 page 51
GSAKMP Application to the IP Security Architecture July, 2004
The GC/KS must process the GSAKMP messages that it receives from
group members originating from any source IP address or source port
number, even if those two values have changed since the last time
that the GC/KS had interacted with a given group member. To identify
the group member, the GC/KS MUST use the GSAKMP signature payload's
identifying information and validate the message's digital
signature.
After processing a message from a group member that requires a GC/KS
response, the GC/KS creates the GSAKMP UDP message destined for the
same IP-v4 address and UDP port that the GC/KS found in the
candidate Group Member message's source IP address and UDP source
port.
6.4.4 GSAKMP Re-key GSA NAT Traversal
The GSAKMP Re-Key GSA is considerably simplified by the constraint
that every Subordinate-GC/KS and Primary-GC/KS MUST straddle a
public Internet/private network boundary adjacent to wherever it has
Group Members behind a NAT gateway. Consequently, a GC/KS may have
Group Members on either side of that boundary, but there is no
intervening NAT gateway tampering with the GC/KS transmissions.
The GC/KS multicasts the GSAKMP Re-Key Event message to the Re-Key
GSA in an ESP protected UDP|NORM|GSAKMP packet addressed to its
(sub-)group's destination public IP-v4 multicast address. The UDP
destination port is set to the GSAKMP-NORM-UDP reserved port number.
The group keyed ESP authenticator protects the UDP payload, so a UDP
checksum MUST NOT be used.
A multi-realm IP-v4 GSAKMP group operates in autonomous distributed
mode. Therefore, each of the group's Subordinate-GC/KS must relay to
their respective sub-group membership the GTEK and policy token that
it extracts from the Primary-GC/KS RKE multicast. The S-GC/KS sends
its RKE message to its sub-group membership from its public Internet
interface.
6.4.5 Application GSA NAT Traversal
Unlike the RKE message multicast to the Re-Key GSA, a multicast
application message sent to the group may originate from a Group
Speaker endpoint located behind a NAT gateway. Since the
application's message is encrypted within an ESP payload, the
transport layer protocol header port fields are concealed from NAT
gateways and they can not participate in NAPT. The multicast
Gross Expires January, 2004 page 52
GSAKMP Application to the IP Security Architecture July, 2004
application GSA must be handled differently depending on whether the
application requires source-specific multicast.
If the application requires source-specific multicast routing, then
there must be a separate public IP-v4 address statically reserved at
the NAT gateway for each Group Speaker endpoint private/public
address mapping. This constraint allows the GC/KS to specify at
every Group Member the inbound SPD traffic selector with a pre-
determined public source address for each Group Speaker endpoint in
the group. The traffic selector's public source address in
combination with the group's destination multicast address and SPI
selects the inbound SA. Keeping the NAT gateway's source address
mapping static rather than dynamic also allows the multicast routers
along the packet's path to apply source-specific routing policies.
Note that the use of a static source address mapping NAT avoids the
need for the group's policy token to specify UDP encapsulated ESP.
The drawback of this approach is that the GC/KS SPD/SAD
configuration database must be kept synchronized with the group's
NAT gateway address mapping configurations. These operational
procedures can be labor-intensive and error-prone, making large-
scale group deployments difficult. The SAM message side steps this
problem (see section 7) by dynamically setting the Group Receiver
endpoint's SPD/SAD entry traffic selector rather than relying on
static GC/KS configuration.
If the application requires the any-source multicast service model,
then the NAT gateway's source address translation can use
dynamically allocated public IP-v4 addresses rather than statically
allocated IP-v4 addresses. However, unless the group uses UDP
encapsulated ESP, then the NAT gateway must have a pool of public
IP-v4 addresses reserved that is at least as large as the number of
Group Speaker endpoints within its private network. The public IP
address pool allows the NAT gateway to do a one-to-one mapping from
every Group Speaker endpoint's private source address to a
dynamically allocated public source address. In this case, the use
of NAPT rather than NAT is not an option, since the transport layer
protocol is within an opaque ESP payload. The GC/KS specifies the
SPD/SAD traffic selector as the combination of the group's
destination multicast address and the SPI.
In some deployments, the number of public IP-v4 addresses assigned
to a NAT gateway is very limited (e.g. only one public address).
Also, it may be difficult to predict how many Group Speaker
endpoints will reside within the private network before the group
begins its operation. For these cases, the group MAY use UDP
Gross Expires January, 2004 page 53
GSAKMP Application to the IP Security Architecture July, 2004
encapsulated ESP. The NAT gateway applies NAPT to the UDP header's
source port field, sidestepping the constraint of its limited public
address pool. The Group Owner modifies the group policy token to
specify that the outbound SPD processing must pre-append a UDP
header in front of the ESP header. When a Group Speaker endpoint
originates a multicast application packet, it inserts a UDP header
in front of the ESP header, as per reference [UDPESP].
7 Security Association Management Message
A Group Speaker multicasts the Security Association Management (SAM)
message to create a Group Security Association's SPD/SAD
configuration at the Group Receiver endpoints. In addition to the
SAM message, the GSAKMP IPsec application extends the GSAKMP base
protocol with three new GSAKMP payload types:
. Security Association Configuration (SAC)
. Identity to Transient Address Mapping (ITAM)
. Transport Endpoint Binding Attribute Certificate (TEBAC) as a
Certificate payload. See section 3.3.3.
Table 1 shows for which GSAKMP messages the ITAM, SAC, and TEBAC
payloads are required, optional, or prohibited.
Exchange Type ITAM Payload SAC Payload TEBAC Payload
RTJ MUST MUST NOT MUST
KDL MAY MUST MUST NOT
KDL-ACK/NACK MUST NOT MUST NOT MAY
RTD MUST NOT MUST NOT MUST
DR MUST NOT MUST NOT MUST NOT
DR-ACK MUST NOT MUST NOT MAY
SAM MUST MUST MUST
RKE MUST MUST MUST
Gross Expires January, 2004 page 54
GSAKMP Application to the IP Security Architecture July, 2004
Table 1 _ ITAM, SAC, and TEBAC payload presence requirements
A Group Speaker endpoint multicasts a SAM message under the
following conditions:
- After the Group Speaker endpoint has sent a KDK-ACK response to
its GC/KS and before it multicasts its first application protocol
data unit, the Group Speaker MUST multicast a SAM message to
create the leading edge GSA SPD/SAD state at its Group Receiver
endpoints.
- Periodically, the Group Speaker multicasts a SAM message at
sufficiently frequent intervals that it replaces the current GSA
with a new leading edge GSA before the current GSA expires due to
elapsed lifetime or reaching its key's cumulative data encryption
limit.
- After each change in one of the Group Speaker's interface
transient IP address assignments. Alternatively, a group security
policy that requires proof of return route-ability will mandate
that the Group Speaker re-register with a GC/KS before sending a
SAM.
Every authorized Group Receiver endpoint receives the SAM message at
the multicast application's destination IP address. The SAM
multicast is a "best effort" UDP payload, and it SHOULD NOT use a
RMTP. Each Group Receiver endpoint validates the Group Speaker's SAM
using the procedure defined by section 7.2. If any of these checks
fail, then the SAM message is discarded.
7.1 GSAKMP Security Association Management Message Syntax
The Security Association Management message comprises a GSAKMP
header encapsulating the sequence of GSAKMP payloads shown in table
2.
Table 2 Security Association Management Message
Message Name : Security Association Management
Dissection : {HDR-GrpID, Nonce-Speaker, Nonce-Membership,
Identity to Transient Address Mapping, {SA-
Config}*, [Key Creation], [Vendor-ID],
[Notification]} SigN, [SpeakerCert],
Gross Expires January, 2004 page 55
GSAKMP Application to the IP Security Architecture July, 2004
[NodeCert], AttribCert
Payload types : GSAKMP header, Nonce, Identity to Transient
Address Mapping, SA-Config, [Key Creation],
[Notification], [Vendor-ID], Signature,
Certificate
SigN : Node Identity's signature
SpeakerCert : The Group Speaker endpoint's signature end-
entity X.509 certificate as profiled in
section 9.2.
NodeCert The Node Identity's signature end-entity
X.509 certificate as profiled in section 9.4
AttribCert : The Node Identity's Transport Endpoint
Binding Attribute Certificate Attribute
Certificate, issued by the Group Speaker
endpoint, as profiled by section 9.6.
{data} SigN : Braces enclose the GSAKMP header and those
payloads that are under the SigN signature
[] : Indicates an optional GSAKMP payload
{payload}* : Braces enclose payload encrypted by the GTEK
Unless stated to the contrary, there can be only one GSAKMP payload
of a given type per SAM message. The SAM GSAKMP payloads under the
signature MAY be in any order, not just the order shown above in
table 1. The Certificate payloads, if any, MUST follow the Signature
payload.
The Transport Endpoint Binding Attribute Certificate is the same one
that was issued by the Group Speaker endpoint to its Node prior to
its registration protocol exchange (see section 4.8). The TEBAC MUST
be present in the SAM message, because it is the Group Speaker
endpoint's authorization of the binding between the Node's signature
identity and the multicast application endpoint attributes asserted
in the SAC and ITAM payloads.
Gross Expires January, 2004 page 56
GSAKMP Application to the IP Security Architecture July, 2004
7.2 SAM Message Verification
A Group Receiver endpoint accepts the SAM message only after it has
successfully executed the following verification steps in the given
order. If any of these steps fail, then the Group Receiver endpoint
MUST discard the SAM message. It MAY log an error but SHOULD NOT
trigger an alarm message (e.g. SNMP TRAP) unless it is rate dampened
and it uses a randomly dithered transmission time.
1. The SAM GSAKMP header and the GSAKMP payloads that the header
envelopes all MUST have the correct length and correct payload
types as defined in section 7.1. There can only be one instance of
the following payload types: SAC, ITAM, Signature, Key Creation,
and Vendor-ID. There can be zero or more instances of the
Notification payload type. There MUST be at least one Certificate
payload which contains the TEBAC. There MUST be two Nonce
payloads, and they respectively contain a Nonce-Speaker nonce type
and a Nonce-Membership nonce type.
2. The GSAKMP header's Group Identifier type MUST be of type "IP-v6",
and it MUST match one of the groups for which the SAM receiving
Node possesses an active membership. A SAM message that arrives at
a Group Receiver endpoint during its registration or de-
registration protocol exchange is not an error but it is silently
discarded.
3. The SAM message depends on its GSAKMP header's sequence number for
anti-replay protection. The Group Receiver endpoint MUST verify
that the SAM GSAKMP header's sequence number is greater than the
previously received SAM message from the same Group Speaker.
Receipt of SAM re-transmission duplicates is possible and they
MUST be silently discarded. The first SAM sequence number
transmitted MUST have the value of one (1). The Group Speaker
advances its GSAKMP header's sequence number after each distinct
SAM message. Group Receiver endpoints MUST NOT update their view
of the SAM sequence number to the value received in the SAM
message's GSAKMP header until all the message's verification steps
complete successfully.
4. The Nonce-Membership payload's value MUST be verified for
freshness and the Group Receiver endpoints MUST confirm that the
Group Speaker endpoint possesses the GTEK. The "Nonce-Speaker"
payload contains a random value that MUST be at least 4 octets in
length. The Nonce-Membership value is the 20 octet HMAC-SHA1 hash
of the group's current policy token concatenated with the Nonce-
Gross Expires January, 2004 page 57
GSAKMP Application to the IP Security Architecture July, 2004
Speaker payload's value. The current GTEK is the key input to that
HMAC-SHA1 operation. The Group Receiver endpoint locally computes
its own view of the Nonce-Membership payload's value. If the
Nonce-Membership value that it computes is the same as the value
found in the Nonce-Membership payload, then that proves the Group
Speaker endpoint possesses the current GTEK.
5. The TEBAC "Issuer" field identifies the Group Speaker endpoint.
This "Issuer" field MUST match one of the group membership
authorization pattern match rules found in the group's current
policy token.
6. The TEBAC "Issuer" field MUST match one of the Group Speaker
authorization pattern match rules found in the group's current
policy token.
7. The TEBAC "Holder" field MUST match the SAM Signature payload's
signer identification value, which is the Node Identity associated
with the Group Speaker endpoint.
8. The Group Receiver endpoint MUST confirm that the Group Speaker's
TEBAC validity period is not expired.
9. The TEBAC "Transport Endpoint Identifier" attribute type MUST
assert the "S" flag.
10. The Group Speaker endpoint's TEBAC "Issuer" signature MUST be
verified, and its signature certificate confirmed to have a chain
of valid certificates rooted at one of the GSAKMP group's trust
anchor Certificate Authorities.
11. The Node Identity's signature in the Signature payload MUST
verify as per [GSAKMP] section 7.8.
12. The Group Receiver endpoint decrypts the SAC payload using the
current GTEK. The SAC payload plain-text's Source Node Identity
field MUST match the Node Identity that signed the SAM message.
7.3 SAM Message Processing After Successful Verification
After all of the section 7.2 SAM message verification checks have
succeeded, then a Group Receiver endpoint can process its payloads.
The SAM message payloads are processed as follows:
Gross Expires January, 2004 page 58
GSAKMP Application to the IP Security Architecture July, 2004
- The ITAM payload binds the Group Speaker's Node Identity to its
associated set of transient locator IP addresses. The Identity to
Transient Address Mapping payload handling is defined in section
7.4.
- The Security Association Configuration payload creates a new Group
Security Association instance by inserting its parameters into a
GSA template's formal arguments as specified by the policy token.
Section 7.5 defines the Security Association Configuration payload
format and its handling.
- The Key Creation payload supports an optional method of creating
peer-to-peer secret keying material and derived security
associations between any two GSAKMP group members that have
multicast a SAM message to the group. The mechanisms that create
and manage those unicast security associations are outside the
scope of this standard. Endpoints that receive a SAM message and
do not participate in the peer-to-peer key management MUST
silently ignore this payload and continue normal processing of the
SAM message.
- The Notification payload is an optional mechanism to supplement
the ITAM and SAC payloads with additional information or status.
See section 7.6. Endpoints that receive a SAM Notification payload
and do not understand the notification code and its contents MUST
silently ignore this payload and continue normal processing of the
SAM message.
- The Vendor-ID payload is an optional mechanism to announce the
presence of vendor-specific information sent from the Group
Speaker to the group's membership. Endpoints that receive a
Vendor-ID payload and do not understand its contents MUST silently
ignore this payload and continue normal processing of the SAM
message. GSAKMP exchange types and payload header types that are
not understood MUST be silently ignored.
7.4 Identity to Transient Address Mapping Payload
The SAM message's ITAM payload keeps the Group Receiver endpoint's
SPD/SAD entries synchronized with NAT and mobility induced changes
in the Group Speaker's IP addresses. The ITAM payload declares the
mapping between three quantities:
1. The Group Speaker's Node Identity, as defined in section 3.1.
Gross Expires January, 2004 page 59
GSAKMP Application to the IP Security Architecture July, 2004
2. The Group Speaker's one or more locator IP interface addresses,
which can change over time due to mobility or other causes (e.g.
DHCP lease expiration).
3. The source IP-v4 address found in the SAM message's IP header,
which may have been assigned by an intervening NAT gateway. Unlike
the previous two quantities, this quantity is not authenticated.
After a GSAKMP Group Receiver endpoint successfully verifies the SAM
message, it populates its local Secure Identity to Address Mapping
(SIAM) database with the ITAM payload's identity to address mapping.
Other system components (e.g. PIM, UDP) may subscribe to the SIAM
event notification service, and receive accurate and authoritative
mappings between a peer system's Node Identity and its transient
locator IP addresses. Figure 1 shows this interface at (C2). The
details of the SIAM implementation and its interactions with other
processes is a local implementation matter outside the scope of this
specification. As a matter of local security policy, the Group
Receiver endpoint MAY also adjust its SPD entries to match the SAM
message's public source IP-v4 address that had been assigned by a
transit NAT gateway. See section 7.7 for discussion of the
tradeoffs.
Figure 3 illustrates the Identity to Transient Address Mapping
GSAKMP payload's bits-on-the-wire format. The "Next Payload", the
"Reserved-1", and "ITAM Payload Length" fields together form the
standard GSAKMP payload header as defined in GSAKMP section 7.1.
Immediately following the GSAKMP payload header, without alignment
padding, is the fixed length portion of the ITAM payload. It
contains the following fields:
- Node Identity _ The Node Identity of the Node originating this
ITAM payload, as per section 3.1.
- Number of interfaces _ The number of interface IP addresses
declared by this ITAM payload, each expressed as a 2-tuple of the
form {Interface local index, transient IP address}. This value
MUST be at least one and it has a maximum value of 31.
- ITAM lifetime _ The duration in seconds after receiving the ITAM
that an endpoint can trust this set of address mappings. The
lifetime is relative to the timestamp in the GSAKMP message's
Signature payload. When the trusted interval expires, then the
Gross Expires January, 2004 page 60
GSAKMP Application to the IP Security Architecture July, 2004
Group Receiver endpoint should no longer accept multicast
transmissions from this Group Speaker endpoint.
After the above fixed length fields, the ITAM payload contains a
variable length array containing one or more interface IP address
structures as its elements. There is a fixed length interface IP
address structure for each of the Node's unicast IP interface
addresses.
Each interface IP address structure has the following fields:
- Reserved-2 field - 14 bits set to zero by sender; it is ignored by
Group Receiver endpoints.
- Interface Address Type (IAT) field _ A two-bit field that
indicates the interface's attached IP network type:
o b'00' _ Global scope unicast IP-v6 address
o b'01' _ IP-v4 address, encoded as a "6to4" IP-v6 unicast
address [RFC3056] with a globally unique unicast IP-v4 address
embedded in its V4ADDR field. The IP-v6 address's Interface
Identifier field low-order 32 bits are the interface's IP-v4
address, which may be allocated from either the public or a
private IP-v4 address spaces. The Interface Identifier field
high-order 32 bits are the Node's controlling GC/KS globally
unique unicast IP-v4 address. Every GC/KS supporting an IP-v4
based GSAKMP group MUST have at least one interface with a
public IP-v4 address. If the Node resides in a private IP-v4
network, then its GC/KS MUST also have at least one IP-v4
interface attached to the same private IP-v4 network as that
Node.
o b'10' _ reserved for future use
o b'11' _ Private IP-v4 address encoded as defined for IAT=b'01',
but with the GC/KS public IP-v4 address unknown, and therefore
this address's Interface Identifier field high-order 32 bits
are set to zero.
- Interface local index _ A unsigned 16-bit integer in network-byte-
order assigned by the Node to represent one of its network
interfaces. Typically the interface local index refers to a link
layer network adapter. Note that multiple IP-v6 addresses MAY
share the same interface local index.
Gross Expires January, 2004 page 61
GSAKMP Application to the IP Security Architecture July, 2004
- Interface IP-v6 address _ The IP interface's unicast IP-v6
address, mapped as specified by the IAT field.
0 1 2 3
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-1 | ITAM Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Node Identity |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITAM Lifetime | number of interfaces |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved-2 |IAT| Interface "A" Local Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Interface "A" IP-v6 address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved-2 |IAT| Interface "B" Local Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Interface "B" IP-v6 address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
. .
. Other Interface addresses .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Identity to Transient Address Mapping GSAKMP payload
After a successful ITAM payload verification, the Group Receiver
endpoint MUST update:
. Those SPD/SAD traffic selectors that reference the Group Speaker
endpoint's previous (i.e. no longer valid) set of transient IP
addresses. The ITAM payload does not alter the Group Speaker
Gross Expires January, 2004 page 62
GSAKMP Application to the IP Security Architecture July, 2004
endpoint's SPI, source port, next layer protocol identifier, or
destination port number assignments.
. Within the Secure Identity/Address Mapping database, the Group
Receiver endpoint updates the Node Identity data structure
selected by the ITAM payload's Node Identity field. The SIAM
process MUST notify those applications that depend on knowing the
revised Node Identity to IP address set mapping. In figure 1, this
is the implementation specific control interface labeled C2.
For both of these databases, the Group Receiver endpoint replaces
the Group Speaker Node's old set of IP addresses with the new set of
IP addresses as declared by the ITAM payload.
7.5 Security Association Configuration Payload
The SAM message's SAC payload creates (or destroys) a Group Security
Association instance at every Group Receiver endpoint. The SAC
payload contains the leading edge GSA traffic selectors, expressed
as a Security Parameter Index (SPI), destination multicast IP
address, source Node Identity, and any GSA related information. The
SAC payload selects one of the GSAKMP IPsec policy token's Security
Association Templates, and every Group Receiver endpoint inserts the
SAC payload's actual parameters into that template's formal
parameters. The Security Association Template originates from the
Group Owner, and it expresses the Group Owner's security policy for
a class of one or more Group Speaker endpoints. See section 7.6.
Each Security Association Template has a set of associated speaker
role authorization rules. These rules pattern match against a Group
Speaker's identity, authorizing which Group Speaker endpoints may
use that template. For some of the actual parameters supplied by the
SAC payload, the template will provide formal parameter constraints
(e.g. numeric ranges) for the acceptable actual parameter values.
Figure 4 illustrates the Security Association Configuration GSAKMP
payload's bits-on-the-wire format. The "Next Payload", the
"Reserved-1", and "SAC Payload Length" fields together form the
standard GSAKMP payload header as defined in [GSAKMP] section 7.1.
The remainder of the SAC payload contains the following fields:
. GSAKMP IPsec policy token sequence number _ This value MUST be
equal to the group's current GSAKMP IPsec policy token sequence
number. If it is not equal, then the GSAKMP message containing
this SAC payload is discarded.
Gross Expires January, 2004 page 63
GSAKMP Application to the IP Security Architecture July, 2004
. Security Association Template identifier _ Refers to a Security
Association Template structure within the current GSAKMP IPsec
policy token. It is an unsigned 32-bit integer in network byte
order. If this identifier does not reference a valid Security
Association Template, then the GSAKMP message containing this SAC
payload MUST be discarded.
. Security Parameter Index (SPI) _ A random value allocated by the
Group Speaker endpoint within the range that has been reserved for
this Group Speaker. The SPI component MUST be unique amongst all
GSA active in the group. It also MUST be unique amongst all of the
SPI allocated by any other groups that share the same multicast
destination IP address. If the GSAKMP group is a Source-Specific
Multicast group then the SPI uniqueness requirement is qualified
by the speaker's source IP address and the group's destination
multicast IP addresses. If the SPI asserted by the SAC payload
collides with an existent GSA, then the GSAKMP message containing
this SAC payload is discarded and an error MUST be logged. See
section 4.11 for additional discussion regarding SPI allocation
coordination among multiple Group Owners.
. Group Traffic Encryption Key identifier
. Group Traffic Encryption Key version
. Group Traffic Authentication Key identifier
. Group Traffic Authentication Key version
. ESP sequence number _ The security association's ESP header first
sequence number, expressed as an unsigned 64-bit integer in
network byte order. When the SAC payload is part of a KDL message,
then a new Group Receiver endpoint can synchronize its receive GSA
state with an existent GSA. A Group Speaker using the GSA re-key
rollover continuity feature MAY multicast a SAM message with a SAC
payload having consecutive ESP sequence numbers across the
transition from the trailing edge to the leading edge GSA time
epochs.
- Source Node Identity _ This value MUST match the Node Identity
asserted in the GSAKMP message's ITAM payload and the Signature
payload's signer identity value. If these Node Identity values do
not match then the GSAKMP message containing the SAC payload MUST
be discarded.
Gross Expires January, 2004 page 64
GSAKMP Application to the IP Security Architecture July, 2004
- Destination multicast IP-v6 address authorized to be used by the
Group Speaker endpoint. If the group is using IP-v4 multicast
distribution then this address is algorithmically translated from
IP-v6 to IP-v4 as per the procedure in section 3.7.
- Next Layer Protocol Identifier _ The GSAKMP group's multicast
application's transport layer protocol identifier (e.g. UDP, NORM,
etc.) as described in section 3.3. Refer to IANA for the current
valid IP header protocol identifier assignments.
- Destination Port _ The multicast application endpoint's
destination port number as described in section 3.3.
- Source Port _ The multicast application endpoint's source port as
described in section 3.3.
- Security Association lifetime _ The GTEK encryption transform hard
time limit, the amount of time that this security association
exists before it self-terminates.
- "D" flag _ A Group Speaker can destroy one of its existent GSA
before the GSA lifetime expires by setting the SAC payload "D"
flag, and sending in a SAM message the same SAC payload parameters
as it had sent in its previous SAM message that referred to the
same GSA.
Gross Expires January, 2004 page 65
GSAKMP Application to the IP Security Architecture July, 2004
0 1 2 3
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-1 | SAC Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GSAKMP IPsec policy token sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association Template identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Traffic Encryption Key identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Traffic Encryption Key version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Traffic Authentication Key identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Traffic Authentication Key version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESP sequence number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source Node Identity |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination Multicast IP-v6 address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Next Layer PID |D| Reserved-3 | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SA Lifetime | Source Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 _ Security Association Configuration GSAKMP payload
Gross Expires January, 2004 page 66
GSAKMP Application to the IP Security Architecture July, 2004
7.6 Security Association Template
The GSAKMP IPsec policy token encodes one or more Security
Association Templates. A Security Association Template declares a
Group Owner's security policy for a class of Group Speaker and Group
Receiver endpoints that share a Group Security Association. Each
such template contains:
. Group Speaker role authorization pattern matching rules, which
represents the set of X.509 identities permitted to become a GSA
Group Speaker using this template.
. The GSA SAD information that is common across all GSA
instantiations based on this template, as described previously in
section 5.5.
. A set of formal parameter constraints on the SAC payload's actual
parameter values. These constraints are represented as the valid
ranges for the following SAC payload parameters. If a SAC payload
asserts a value outside of its associated template's range, then
the SAC payload and its GSAKMP message MUST be discarded.
o Source Node Identity's GSAKMP IPsec group sub-net identifier
o Destination multicast IP-v6 address
o Next layer protocol identifier
o Destination port
o Security association hard limit lifetime
o Security Parameter Index
. Tunnel mode GSA information, as per section 5.10
. If the GSAKMP group policy requires that the Group Speaker use
digital signature multicast source authentication, then the
Security Association Template specifies the Group Speaker's source
authentication protocol, algorithm, and related parameters. Some
source authentication algorithms (e.g. TESLA) will require that
the GSAKMP IPsec policy token announce other algorithm-specific
parameters.
Gross Expires January, 2004 page 67
GSAKMP Application to the IP Security Architecture July, 2004
7.7 GC/KS Co-located at the Transit NAT Gateway
For a GSAKMP multi-realm IP-v4 based group, special processing
occurs for a Group Speaker's SAM message. If none of the Group
Speaker's interface IP-v4 addresses within the ITAM payload match
the SAM message's IP header source IP-v4 address, then a transit NAT
gateway translated that address while the datagram was in transit.
Since the NAT gateway's alteration is not authenticated, the GSAKMP
group policy must pick one of two alternatives:
1. Assume that the translated source IP-v4 address is sufficiently
trustworthy without proof of return route-ability, and the Group
Receiver endpoints immediately modify their SPD/SAD to use that
address for the Group Speaker's traffic selector entries.
2. The translated source IP-v4 address is not sufficiently
trustworthy "as is", and it should not be installed in the Group
Receiver endpoint's SPD/SAD traffic selectors until it is
substantiated by a re-registration. All GSAKMP IPsec IP-v4
implementations MUST support this policy.
The second group policy requires that the Group Speaker endpoint re-
register with the GC/KS (section 4.8) co-located with the transit
NAT gateway at the public/private network boundary. The cookies
exchange proves the return route-ability of the translated source IP
address. After its re-registration completes, the Group Speaker
multicasts the SAM message to the Group Receiver endpoints. The
Group Receiver endpoints confirm that one of the ITAM payload's
interface IP address structures has an IAT field set to b'01' with
an interface IP-v6 address containing the GC/KS public IP-v4 address
in its Interface Identifier. The GC/KS public IP-v4 address MUST
match the SAM message's translated source IP address.
The drawback of the proof of return route-ability policy is its high
latency penalty that interrupts continuous streaming media
transmission from the Group Speaker endpoint.
7.8 SAM Notification Payload Handling
To be defined.
8 NACK-Oriented Reliable Multicast Protocol Profile
At the time of this writing, the Negative-acknowledgement Oriented
Reliable Multicast (NORM) protocol is an IETF experimental track
Gross Expires January, 2004 page 68
GSAKMP Application to the IP Security Architecture July, 2004
specification being developed in the Reliable Multicast Transport
(RMT) working group. NORM is a general-purpose facility that
accommodates many diverse multicast applications. For its purposes,
the GSAKMP IPsec application only needs the simple subset of the
NORM protocol that is optimal for the GSAKMP RKE message reliable
multicast transport.
This section prescribes an interoperable profile based on the NORM
protocol as it exists at the time of this writing. The expectation
is that in the long-term, this profile will be deprecated and
altogether replaced by the NORM protocol when it makes its planned
transition to IETF proposed standard status. Until then, compliant
GSAKMP IPsec implementations MUST support the use of the NORM
protocol subset defined herein for reliable RKE message delivery.
8.1 GSAKMP/NORM Subsystem Mandatory Features
There is only one GC/KS NORM session per GSAKMP group, or else when
in autonomous distributed mode then there is one S-GC/KS NORM
session per GSAKMP sub-group. This GC/KS NORM session is independent
from any NORM sessions that might be created in the same group by
the multicast application. The GC/KS is the NORM session's only
multicast sender. The NORM protocol messages are UDP encapsulated,
and they are protected by a GSAKMP ESP Group Security Association.
Referring to the figure 1 data flow (D2), the protocol stack is as
follows:
IP|ESP|UDP|NORM|GSAKMP RKE payload
The GC/KS NORM session's UDP destination port number is GSAKMP-NORM-
UDP (value TBD by IANA). A NORM message's NormNodeId is the SHA hash
of the source Node's Node Identity truncated to use the low-order 32
bits. The NormTransportId monotonically increases for each RKE
multicast. The GSAKMP/NORM subsystem assigns the NormInstanceId;
this value SHOULD be unique across GC/KS re-boots.
The NORM-FLAG-MSG-START marks the start of each RKE message
boundary. The NORM-FLAG-INFO, NORM-FLAG-STREAM, NORM-FLAG-FILE, and
NORM-FLAG-UNRELIABLE flags MUST NOT be set.
The NORM-ROBUST-FACTOR is a tunable quantity that controls how many
NORM retry attempts are allowed by the error recovery procedure. It
SHOULD be configurable by the GSAKMP Group Owner management
interface. The RECOMMENDED value is 3.
Gross Expires January, 2004 page 69
GSAKMP Application to the IP Security Architecture July, 2004
The GSAKMP/NORM subset MUST NOT use the NORM "ack node" list
capability.
The GSAKMP/NORM subsystem MUST support the following protocol
message types:
- NORM-DATA messages only specify the NORM-OBJECT-DATA attribute.
Section 8.Y gives constraints on the NORM-DATA Forward Error
Correction (FEC) algorithms and payloads.
- NORM-CMD(FLUSH)- This command is sent by the GC/KS sender after
the last FEC payload segment of a RKE transmission.
- NORM-CMD(SQUELCH)
- NORM-CMD(CC) _ congestion control
- NORM-CMD(REPAIR-ADV) _ sender's repair state advertisement
- NORM-NACK
- NORM-ACK
Any of the NORM protocol optional message types MAY be supported by
a GSAKMP/NORM implementation, however, these messages types MUST NOT
be used with a GC/KS NORM session. They MAY be used with other
multicast application NORM sessions, i.e. the figure 1 data flow
labeled (D1).
8.2 Forward Error Correction Algorithms
To be defined.
8.3 Group-wide Default Path MTU Length
The NormSegmentSize is less than the path MTU, as it MUST be
adjusted to subtract the overhead length of the IP header, IP-v6
extension headers (if any), AH (if any), ESP header, ESP trailer,
UDP header, and NORM header. For IP-v6, the default path MTU is
1280. For IP-v4, the default path MTU is 580 bytes.
Gross Expires January, 2004 page 70
GSAKMP Application to the IP Security Architecture July, 2004
9 GSAKMP IP Security Public Key Infrastructure Profile
This section profiles the GSAKMP IPsec subsystem's requirements and
certificate conventions for its supporting Public Key
Infrastructure. Figure 1 shows the GSAKMP/PKI interface at (C1).
As its guiding principle, the GSAKMP IPsec architecture creates a
short-lived attribute certificate that binds each application
endpoint in a GSAKMP group to a Node Identity before starting a
Node's GSAKMP protocol exchanges on behalf of that application
endpoint. Both the application endpoint identity and the Node
Identity are long-lived in comparison to the attribute certificate.
This approach allows an application endpoint identity representing a
roaming GSAKMP end user to dynamically bind to a Node for the
duration of a group membership, rather than assuming a permanent
static relationship. A short lived attribute certificate also avoids
the complexity of a revocation mechanism.
9.1 Identification and Signature Payload Signer ID Types
The [GSAKMP] table 19 defines the GSAKMP identification types that
match against certificate identities and SPD symbolic name
selectors. These identification types are used by both
Identification payloads and also for the Signature payload's signer
identification type. The GSAKMP IPsec application requires that
GSAKMP IPsec implementations MUST support both sending and receiving
of the following identification types in the Identification and
Signature payloads:
. ID-IPV4-ADDR
. ID-FQDN
. ID-IPV6-ADDR
. ID-RFC822-ADDR
. ID-DER-ASN1-DN
. ID-UNENCODED-UNAME
The ID-IPV4-ADDR, ID-FDQN, ID-IPV6-ADDR, and ID-RFC822-ADDR MUST
exactly match the corresponding certificate "SubjectAltName" field.
The SPD symbolic name selector MUST support exact matching against
Gross Expires January, 2004 page 71
GSAKMP Application to the IP Security Architecture July, 2004
these identification types and MAY support wildcard or regular
expression string matching.
The ID-DER-ASN1-DN MUST match the certificate's "Subject" field
using bit-by-bit comparison. The SPD symbolic name selector MUST
support any combination of the "C", "CN", "O", or "OU" attributes.
The ID-KEY-ID identification type is not standardized by this
profile and SHOULD NOT be used.
9.2 Application Endpoint Signature Certificate
The application endpoint end-entity signature certificate profile
strikes a balance between accommodating existing PKI certificate
deployments, and constraining those certificates to avoid the inter-
operability problems witnessed in RFC2401 compliant IPsec/IKE
deployments. This profile subsets the [GSAKMP] requirement for
compliance with the [RFC3280] profile and further requires that it
MUST be a X.509-v3 certificate. Unless qualified to the contrary by
this specification, a certificate inherits whatever RFC3280 has
profiled.
9.2.1 Subject Field Distinguished Name
The Subject field X.500 distinguished name MUST NOT be empty, as
issuing the TEBAC has a dependency on its value (see section 9.6.1)
The Subject field MUST declare the "C", "CN", "O", and "OU"
attributes.
9.2.2 SubjectAltName Extension
If the SubjectAltName extension is present, it SHOULD be a
rfc822Name, ipAddress, or dNSName. It MUST NOT be an otherName,
x400Address, directoryName, ediPartyName, or registeredID.
9.2.3 Issuer Field
To be defined.
9.2.4 Key Usage and Extended Key Usage Fields
To be defined.
Gross Expires January, 2004 page 72
GSAKMP Application to the IP Security Architecture July, 2004
9.3 GSAKMP Certificate Payload Types
Compliant GSAKMP IPsec implementations MUST be able to send,
receive, verify, and process Certificate payloads containing X.509-
v3 end-entity and intermediate CA signature certificates ([GSAKMP]
table 20, certificate type 4). The Transport Endpoint Binding
Attribute Certificate when sent in a Certificate payload uses
[GSAKMP] table 20 certificate type 10.
9.4 Node Identity End-Entity Public Key Certificate
Each Node MUST have an X.509-v3 end-entity signature public key
certificate that meets the profile given in this section. There is
usually only one Node Identity signature public key/secret key pair
per Node, rather than one such key pair per GSAKMP group that the
Node is a participant. For all of the GSAKMP groups managed by a
given Group Owner, the Node uses its Node Identity certificate to
prove its identity in all of those groups that it participates. As
its starting point, the Node Identity certificate MUST conform to
the [RFC3280] profile. This section further qualifies the required
usage and values for many of that certificate's fields.
The Group Owner management system MAY be the Certificate Authority
for the Node Identity certificate issued to a Node. Alternatively,
the GSAKMP Group Owner management system oversees the Node Identity
certificate lifecycle through a Certificate Management System
interface that is outside the scope of this standard. However, in
either case the Group Owner MUST enforce the Node Identity
uniqueness requirement across all of its registered Nodes. It is
RECOMMENDED that the Node Identity key pair creation and certificate
enrollment process occur as a part of a Node's GSAKMP IPsec
subsystem installation process.
The Node Identity certificate's "signatureAlgorithm" MUST be either
be DSA-SHA1 or RSA-MD5 as per [PKIXALGS].
9.4.1 Subject and SubjectAltName Extension
The Node Identity certificate MUST have an IP-v6 address
"subjectAltName" critical extension, with its value set to the Node
Identity IP-v6 address as defined in section 3.1. The Node Identity
certificate MUST have a Subject field distinguished name conformant
to the profile in 9.2.1. In addition, the Node Identity public key
certificate MAY also have a Fully Qualified Domain Name or IP-v4
Gross Expires January, 2004 page 73
GSAKMP Application to the IP Security Architecture July, 2004
address "subjectAltName" field. It SHOULD NOT have a RFC822 name as
a "subjectAltName".
9.4.2 Unique Identifiers
As specified by [RFC3280] section 4.1.2.8, the Node Identity
certificate MUST NOT use the "issuerUniqueID", and "subjectUniqueID"
fields.
9.4.3 Key Usage and Extended Key Usage Extensions
The "keyUsage" extension MUST be present and marked as critical. It
MUST indicate that the Node Identity's public key can be used to
validate a digital signature. Other key usage flags MUST NOT be
asserted. The Extended Key Usage extension MAY be present but it
MUST NOT be marked critical. Interpreting its value is a local
matter set by Group Owner policy.
9.4.4 Certificate Policies Extension
To be defined.
9.4.5 Subject Key Identifier Extension
The subject key identifier extension MUST be present in the Node
Identity certificate and it MUST NOT be marked critical. The
"keyIdentifier" SHOULD be the 160-bit SHA1 hash of the public key.
9.4.6 Authority Key Identifier Extension
The Authority Key Identifier extension MUST be present in the Node
Identity certificate.
9.4.7 Basic Constraints Extension
If the "BasicConstraints" extension is present then it MUST have the
"cA" boolean set to FALSE.
9.5 Group Trust Anchor Public Key Certificate Key-ring
The PAD defines the trust anchor public key certificates for each
GSAKMP group. These MAY be organized as a database containing one or
more key-rings, each indexed by a key-ring identifier. A key-ring in
that database contains one or more Certificate Authority
certificates or else references to where those certificate can be
Gross Expires January, 2004 page 74
GSAKMP Application to the IP Security Architecture July, 2004
retrieved and/or verified (e.g. an LDAP directory). The GSAKMP IPsec
management interface MUST have the ability to associate each GSAKMP
group with a single key-ring or an equivalent trusted database. The
key-ring MUST support at least two CA certificates. Other key-ring
and Public Key Infrastructure configuration management facilities
(i.e. add/remove certificates to/from the key-ring) SHOULD be
implemented.
9.6 Transport Endpoint Binding Attribute Certificate
The Transport Endpoint Binding Attribute Certificate is an GSAKMP
IPsec interpretation of "An Internet Attribute Certificate Profile
for Authorization" [RFC3281]. The RFC3281 mandates the X.509-2000
version 2 definition of an attribute certificate. Any attribute
certificate field not explicitly qualified herein simply inherits
the RFC3281 definition.
9.6.1 IssuerName Field
To comply with [RFC3281] section 4.2.3, the "issuerName" MUST
contain a single "GeneralName" having a non-empty distinguished name
in its "directoryName" field. This constraint prohibits the use of
those application endpoint end-entity certificates that have an
empty distinguished name as a TEBAC issuer entity. The distinguished
name MUST conform with the rules given in this document's section
9.2. The "baseCertificateID" and "objectDigestInfo" forms of
"issuerName" MUST NOT be used.
9.6.2 Holder Field
The X.509 attribute certificate's "Holder" field is a SEQUENCE OF
options, for which a TEBAC MUST have only one instance of the
"baseCertificateID" option. The "entityName" and "objectDigestInfo"
options MUST NOT be used in the TEBAC "Holder" field. The Node
Identity signature public key certificate's "serialNumber" and
"issuer" fields are identical to the TEBAC "Holder" field.
9.6.3 TEBAC Issuer Signature Algorithm
The TEBAC signature algorithm MUST be DSA-SHA1 as per [PKIXALGS].
9.6.4 Validity Period and TEBAC Revocation Strategy
It is an explicit GSAKMP IPsec security assumption that the TEBAC
validity period is short-lived and that certificate revocation
Gross Expires January, 2004 page 75
GSAKMP Application to the IP Security Architecture July, 2004
status does not need to be maintained. The validity period is set by
the application endpoint issuer's security policy. The TEBAC
validity period SHOULD be tailored to minimally bracket the
application endpoint's predicted GSAKMP group membership lifetime.
Alternatively, the validity period MAY bracket each GSAKMP protocol
exchange, although this incurs the overhead of issuing a TEBAC more
frequently. Consequently, the "noRevAvail" extension MUST be present
in the TEBAC. The authority information access and CRL distribution
point extensions MUST NOT be present in the TEBAC.
When validating a "attrCertValidityPeriod", the GC/KS MUST compare
it against both the GSAKMP message's Signature payload Signature
Timestamp field ([GSAKMP] figure 21, section 7.8) and also the local
system's clock.
9.6.5 Attribute Certificate Targeting Extension
The Attribute Certificate Targeting extension prescribes the set of
GC/KS authorized to provide GSAKMP group management services for the
issuer application endpoint. However, this version of the GSAKMP
IPsec profile does not require GC/KS to inspect and act on the
contents of this TEBAC field. A TEBAC MAY be issued without the
"attrCertTargeting" extension and the GC/KS verifiers MAY ignore
this extension.
9.6.6 Group Attribute Type
The "Group" attribute type MUST be present within the TEBAC
Attributes field. The "Group" attribute type is a set of one or more
values, and each such value MUST specify a valid GSAKMP IPsec group
identifier, as defined in section 3.2. The TEBAC "Group" attribute
type SHOULD have only one GSAKMP group value. The application
endpoint authorizes the Node Identity to sign its GSAKMP messages
for each of the GSAKMP groups named by the "Group" attribute. The
"Group" field's value encoding MUST compare equal on a bit by bit
basis with the GSAKMP group header's group identifier value as per
[GSAKMP] section 7.1.1.1.4.
9.6.7 Access Identity Attribute Type
The TEBAC profile defines a "transportEndpointIdentifier" data
structure mapping on the "accessIdentity" attribute type (refer to
RFC3281 section 4.4.2). The transportEndpointIdentifier represents
the transport layer endpoint identifier for which the TEBAC issuing
application endpoint authorizes a Node Identity to sign GSAKMP
Gross Expires January, 2004 page 76
GSAKMP Application to the IP Security Architecture July, 2004
messages and setup SPD/SAD entries on its behalf. The TEBAC "Access
Identity" attribute type MUST be present in the TEBAC "Attributes"
field, and that attribute type MUST have only one fixed length
value. The Access Identity attribute's value is in "SvceAuthInfo"
syntax, but MUST NOT have the "authInfo" component.
The SvceAuthInfo "service" component encodes the GSAKMP message
signer's delegated authority. The "service" is a GeneralName OCTET
STRING. It is encoded in one octet as a set of bit flags authorizing
which types of GSAKMP messages that the Holder Node Identity may
sign on behalf of the Issuer application endpoint. Multiple flags
may be OR'ed together:
o Group Speaker mode membership registration, 0x01
o Group Receiver mode membership registration, 0x02
o De-registration,0x04
o Group management (RKE), 0x08
o All other bits reserved for IANA allocation, and set to zero
The SvceAuthInfo "ident" component concatenates the following
TransportEndpointIdentifier data structure fields in the following
order:
. TransportEndpointIdentifier version number, 1 octet, set to zero
for this specification version. This value maps the
TransportEndpointIdentifier data structure, allowing new fields to
be defined in a future specification revisions.
. Application endpoint's identification type, 1 octet, as defined by
[GSAKMP] table 19. This document's section 9.1 defines which
identification types from [GSAKMP] table 19 MUST be supported by a
TEBAC. The identification type selects one among the multiple
identifiers (e.g. one value from the SubjectAltName list) within
the application endpoint's certificate. The GC/KS uses the
selected identity in the application endpoint's group membership
and group speaker role authorization pattern matching process.
. Next layer protocol identifier, 1 octet.
. Source port number, 2 octets in network-byte-order,
Gross Expires January, 2004 page 77
GSAKMP Application to the IP Security Architecture July, 2004
. Destination port number, 2 octets in network-byte-order
See section 3.3 for additional information about these components.
The Node Identity is implicitly part of this
TransportEndpointIdentifier data structure, and its value is found
in the SubjectAltName of the certificate referenced by the Holder
field.
9.6.8 Optional Attribute Types
There are non-critical yet standard Attribute Types in [RFC3281].
This TEBAC profile does not specify how to apply the following
Attribute Types to the GSAKMP IPsec context:
. Service Authentication Information
. Clearance
. Charging Identity _ This attribute type MAY be used to assist AAA
related charge back for GSAKMP group services.
10 Security Considerations
To be defined in a future edition of this document.
11 IANA Considerations
11.1 GSAKMP IPsec Specific Allocations
The GSAKMP IPsec application allocates the following new values
beyond those defined by the [GSAKMP] core protocol specification:
. GSAKMP exchange type for the Security Association Management
message, IANA allocated from [GSAKMP] table 13.
. GSAKMP payload next header type for the Identity to Transient
Address Mapping payload, IANA allocated from [GSAKMP] table 12.
. GSAKMP payload next header type for the Security Association
Configuration payload, IANA allocated from [GSAKMP] table 12.
. A UDP port number for GSAKMP payloads encapsulated by a UDP
header followed by a NORM protocol header.
Gross Expires January, 2004 page 78
GSAKMP Application to the IP Security Architecture July, 2004
11.2 SAM Message Nonce Types
The GSAKMP Security Association Message contains two Nonce payloads,
each having a new nonce type. GSAKMP IPsec requires that two code-
points be allocated from the [GSAKMP] table 27 reserved to IANA
range:
Nonce Type Code Point Definition
Nonce-Speaker TBD by IANA Section 7.2
Nonce-Membership TBD by IANA Section 7.2
11.3 GSAKMP IP Security Specific Notify Payload Error Codes
The [GSAKMP] table 21 reserves the GSAKMP Notification Type range.
This specification allocates the following Notification Types for
GSAKMP IPsec related error conditions. An IP Security error
condition can trigger sending a Notification payload as part of the
registration protocol exchange, the de-registration exchange, or it
can be used as a value recorded in a log file (e.g. an error logged
during RKE policy token processing). GSAKMP IPsec implementations
MUST be capable of generating the following error code points:
Error GSAKMP/IPsec Error Description Section defining
code the error trigger
34 SAC payload configuration error 7.5, 7.6
35 SPI range overlap detected 4.11, 7.2
35 Group Speaker Attribute Certificate 4.8, 7.2
not acceptable
36 Candidate group member not 4.8
authorized to be a speaker
37-66 Reserved for future allocation
Gross Expires January, 2004 page 79
GSAKMP Application to the IP Security Architecture July, 2004
12 Acknowledgements
The author wishes to acknowledge the contribution of Stephen
Farrell, who reviewed and offered guidance for the attribute
certificate related aspects of section 9.
13 Normative References
GSAKMP Group Security Association Key Management Protocol
(GSAKMP), H. Harney, U. Meth, A. Colegrove, G. Gross,
draft-ietf-msec-gsakmp-sec-06.txt, June 2004, work in
progress.
RFC3280 Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile, R.
Housley, W. Polk, W. Ford, D. Solo, April 2002.
RFC3281 An Internet Attribute Certificate Profile for
Authorization, R. Housley, S. Farrell, April 2002.
PKIXALGS
IPSECPT The GSAKMP IP Security Policy Token Extension, G.
Gross, work in progress, to be published.
RFC2401bis Security Architecture for the Internet Protocol, S.
Kent, K. Seo, April 2004, draft-ietf-ipsec-
rfc2401bis-02.txt, work in progress.
14 Informative References
RFC1918 Address Allocation for Private Internets. Y. Rekhter,
B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear.
February 1996.(Status: BEST CURRENT PRACTICE)
RFC2663 IP Network Address Translator (NAT) Terminology and
Considerations. P. Srisuresh, M. Holdrege. August
1999. (Status: INFORMATIONAL)
RFC3022 Traditional IP Network Address Translator
(Traditional NAT). P. Srisuresh, K. Egevang. January
2001. (Status: INFORMATIONAL)
Gross Expires January, 2004 page 80
GSAKMP Application to the IP Security Architecture July, 2004
UDPESP UDP Encapsulation of IPsec Packets, A. Huttunen,
B. Swander, V. Volpe, L. DiBurro, M. Stenberg,
February 16, 2004, draft-ietf-ipsec-udp-encaps-
08.txt, work in progress.
IKE-V2 Internet Key Exchange (IKEv2) Protocol, C. Kaufman
(Ed.), March 22, 2004, draft-ietf-ipsec-ikev2-13.txt,
work in progress.
IPSECNAT Negotiation of NAT-Traversal in the IKE, T. Kivinen,
A. Huttunen, B. Swander, V. Volpe, 10 Feb 2004,
draft-ietf-ipsec-nat-t-ike-08.txt, work in progress
RFC2529 Transmission of IPv6 over IPv4 Domains without
Explicit Tunnels. B. Carpenter, C. Jung. March 1999.
RFC3235 Network Address Translator (NAT)-Friendly Application
Design Guidelines. D. Senie. January 2002. (Status:
INFORMATIONAL)
RFC3027 Protocol Complications with the IP Network Address
Translator. M. Holdrege, P. Srisuresh. January 2001.
(Status: INFORMATIONAL)
RFC3590 Source Address Selection for the Multicast Listener
Discovery (MLD) Protocol. B. Haberman. September
2003.
RFC3678 Socket Interface Extensions for Multicast Source
Filters, D. Thaler, B. Fenner, B. Quinn, January 2004
(Status: INFORMATIONAL)
RFC3056 Connection of IPv6 Domains via IPv4 Clouds. B.
Carpenter, K. Moore. February 2001.
RFC2588 IP Multicast and Firewalls. R. Finlayson. May 1999.
(Status: INFORMATIONAL)
RFC2709 Security Model with Tunnel-mode IPsec for NAT
Domains,. P.Srisuresh. October 1999. (Status:
INFORMATIONAL)
Gross Expires January, 2004 page 81
GSAKMP Application to the IP Security Architecture July, 2004
15 Author Contact Information
George M. Gross
IdentAware Security
82 Old Mountain Road
Lebanon, NJ 08833
908-268-1629
gmgross@identaware.com
16 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.
17 Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Gross Expires January, 2004 page 82
GSAKMP Application to the IP Security Architecture July, 2004
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 assigns.
18 Disclaimer Statement
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
19 APPENDIX A
To be supplied.
Gross Expires January, 2004 page 83