Internet Engineering Task Force Mark Baugher(Cisco)
INTERNET-DRAFT Thomas Hardjono (Verisign)
Hugh Harney (Sparta)
Brian Weis (Cisco)
November 21, 2001
The Group Domain of Interpretation
<draft-ietf-msec-gdoi-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.
Abstract
This document presents an ISAMKP Domain of Interpretation (DOI) for
group key management to support secure group communications. The
"GDOI" borrows definitions from GSAKMP, incorporates the Phase 1 SA of
the Internet DOI, and proposes new payloads and exchanges according to
the ISAKMP standard. The GDOI manages group security associations,
which are used by security protocols running at the IP or application
layers. These security associations protect one or more key-
encrypting keys, traffic-encrypting keys, or data shared by group
members.
Comments on this document should be sent to msec@securemulticast.org.
Table of Contents
1.0 Introduction
2.0 Motivation for Using ISAKMP
2.1 Disadvantages of using ISAKMP
2.2 Advantages of using ISAMKP
2.3 Overview of IKE
2.4 Use of IKE Phase 1 as a Secure Channel
2.4.1 IKE Phase 1 SA Payload
2.4.2 Use of the IKE UDP port.
3.0 GROUPKEY-PULL Exchange
3.1 ACL-based Versus Credential-based Authorization
3.2 Messages
3.2.1 Perfect Forward Secrecy
3.2.2 ISAKMP Header Initialization
3.3 Initiator Operations
3.4 Receiver Operations
3.5 Use of Data Security Protocols for the Secure Channel
4.0 GROUPKEY-PUSH Message
4.1 Perfect Forward Secrecy (PFS)
4.2 Forward and Backward Access Control
4.3 Delegation of Key Management
4.4 ISAKMP Header Initialization
4.5 Deletion of SAs
5.0 Payloads and Defined Values
5.1 Identification Payload
5.1.1 Identification Type Values
5.1.1.1 ID_KEY_ID
5.2 Security Association Payload
5.2.1 Payloads following the SA payload
5.3 SA KEK payload
5.3.1 KEK Attributes
5.3.2 KEK_MANAGEMENT_ALGORITHM
5.3.3 KEK_ALGORITHM
5.3.4 KEK_KEY_LENGTH
5.3.5 KEK_KEY_LIFETIME
5.3.6 SIG_HASH_ALGORITHM
5.3.7 SIG_ALGORITHM
5.3.8 SIG_KEY_LENGTH
5.3.9 KE_OAKLEY_GROUP
5.4 SA TEK Payload
5.4.1 PROTO_IPSEC_ESP
5.4.2 Other Security Protocols
5.5 Key Download Payload
5.5.1 TEK Download Type
5.5.2 KEK Download Type
5.5.3 LKH
5.5.4 OFT
5.6 Sequence Number Payload
5.7 Proof of Possession
5.8 Nonce
6.0 Application Scenarios
6.1 Data Broadcast
6.2 Video-on-demand
6.3 Summary
7.0 Security Considerations
8.0 IANA Considerations
8.1 ISAKMP DOI
8.2 Payload Types
8.3 New Namespaces
9.0 Acknowledgements
10.0 References
Authors Address:
Appendix A: Sample GDOI definitions for MESP and AMESP
A.1 SA TEK bindings
A.2 MESP/AMESP SA TEK Attributes
A.2.1 GS_ORDER
A.2.2 GS_PROTOCOL
A.2.3 GS_TRANSFORM
A.2.4 GS_TRANSFORM_KEY_LENGTH
A.2.5 GS_TRANSFORM_KEY_LIFETYPE
A.2.6 GA_ORDER
A.2.7 GA_PROTOCOL
A.2.8 GA_TRANSFORM
A.2.9 SrA_ORDER
A.2.10 SrA_PROTOCOL
A.2.11 SrA_ALGORITHM
A.3 TESLA SA TEK Attributes
A.3.1 SOURCE_ID
A.3.2 DIRECT_SYNCHRONIZATION
A.3.3 SENDERS_CERT_TYPE
A.3.4 SENDERS_CERT
A.3.5 HMAC_TYPE
A.3.6 KEY_CHAIN_PRF
A.3.7 INTERVAL_TIME
A.3.9 INTERVAL_DURATION
A.3.10 KEY_DISCLOSURE_DELAY
Appendix B: LKH Data Key Download Definitions
B.1 LKH Key Data (KD) Payload definitions
B.1.1 KEK_LKH
Appendix C: Sample GDOI Definitions for SRTP
C.1 SRTP Namespace: SA TEK Bindings
C.2 SRTP Namespace: SA TEK Attributes
C.2.1 SSRC
C.2.2 DESTINATION_ADDRESS
C.2.3 DESTINATION_RTP_PORT
C.2.4 DESTINATION_RTCP_PORT
C.2.5 ROLLOVER_COUNTER
C.2.6 CIPHER
C.2.7 CIPHER_MODE
C.2.8 CIPHER_KEY_LENGTH
C.2.9 SALT_KEY_LENGTH
C.2.10 AUTHENTICATION_ALGORITHM
C.2.11 WINDOW_SIZE
C.2.12 SRTCP_INDEX
1.0 Introduction
This document presents an ISAMKP Domain of Interpretation (DOI) for
group key management [GKMARCH]. The GDOI incorporates the Phase 1 SA
of the Internet DOI [RFC2407, RFC2409], and proposes new payloads and
exchanges according to the ISAKMP standard [p. 14 RFC2408,].
There are several new payloads:
1) GDOI SA
2) SA KEK (SAK) which follows the SA payload
3) SA TEK (SAT) which follows the SA payload
4) Key Download Array (KD, or Key Download in GSAKMP)
5) Sequence number (SEQ)
6) Proof of Possession (POP)
There are two new exchanges.
1) A Phase 2 exchange creates Category-2 or Category-3 SAs.
The new Phase 2 exchange, called "GROUPKEY-PULL," downloads keys
for group key management (an SA that includes a key encrypting key, or
KEK, common to the group) or for security protocols [Section 2.1
RFC2407], which consist of an SA that includes a data encryption key,
or TEK. The SA [Section 4.6.2 RFC2401] for the KEK or TEK includes
authentication keys, encryption keys, cryptographic policy, and
attributes specific to the data security protocol (see Appendices of
this document). The GROUPKEY-PULL exchange uses "pull" behavior since
the Member initiates the retrieval of these SAs from a group
controller and key server ("GCKS"). The Member is aware of the Group
through some out-of-band announcement scheme (such as Session
Description Protocol) and initiates the pull.
2) A datagram creates or modifies Category-2 and Category-3 SAs.
The GROUPKEY-PUSH datagram is "pushed" from the GCKS to the Members.
A KEK or KEK array protects the GROUPKEY-PUSH message, which creates a
new Category-2 or Category 3 SA. A Category-2 SA protects GROUPKEY-
PUSH messages (i.e. it contains the group KEK). A Category-3 SA is a
Data Security protocol SA - GDOI passes this information to the
particular Data Security Protocol (IPsec, SRTP, AMESP). Multiple
Category-3 SAs can be specified through the SAT. The GCKS or Delegate
creates each Category-3 SA with a TEK (carried in KD) on behalf of a
Security Protocol, which secures a new data session (e.g., IP
multicast file transfer). A Security Protocol uses the TEK and "owns"
the Category-3 SA in the same way that IPsec ESP uses the IKE Phase 2
keys and owns the Phase 2 SA. When the GROUPKEY-PUSH message carries
a KEK array, it creates a new Category-2 SA. The GKCS or Delegate
creates a new Category-2 SA with a KEK array in order to add or remove
group members using a membership management protocol [RFC2627, GSAKMP,
OFT]. Alternatively, membership may expire when the KEK expires
[MARKS] and the GROUPKEY-PUSH message is not used to create Category-2
SAs for the particular Group. Use of LKH-style membership management
is an option in the GDOI.
The GROUPKEY-PULL exchange resembles the GSAKMP Group Establishment
procedure and gthe GROUPKEY-PUSH resembles GSAKMP Re-key [GSAKMP].
Unlike GSAKMP, GDOI uses IKE exchanges (the Phase 1 exchanges) and
definitions. GDOI uses an IKE-compliant header in which "GDOI" is the
declared domain of interpretation used in the IKE Phase 1 and
subsequent GDOI Phase 2 (GROUPKEY-PULL) exchanges.
Thus GDOI is a group security association management protocol: All
GDOI messages are used to create, maintain, or delete security
associations for a group. As described above, these security
associations protect one or more key-encrypting keys, traffic-
encrypting keys, or data shared by group members.
2.0 Motivation for Using ISAKMP
The ISAKMP protocol is a key management framework for transferring key
and authentication data independent of the key generation process
[Section 1 RFC2408]. ISAKMP defines a set of protocol exchanges that
set up a secure channel for key management, as well as the exchange of
key and authentication data.
Generalized payloads for exchanging key generation and authentication
data are defined by ISAKMP. These payloads are combined with a Domain
of Interpretation (DOI), which defines the specifics of key exchange
protocol.
ISAKMP is intended to support the negotiation of SAs for Security
Protocols at all layers of the network stack, although in practice it
is commonly used at the network layer.
2.1 Disadvantages of using ISAKMP
A generalized protocol such as ISAMKP has a tendency towards
complexity. This complicates security reviews of the protocol [FS00].
Protocol complexity may also lead to implementation errors.
2.2 Advantages of using ISAMKP
The IKE protocol is a widely-deployed key exchange protocol that
supports new DOIs [Section 4 RFC2409]. It is primarily used as a key
exchange protocol for IPSEC, but can be used for other security
protocols as well. IPSEC protocols have been deployed in the majority
of all internetworking devices as well as end-user host products. As
IPSEC support has grown, support for the IKE protocol has proliferated
as well. As a measure of IPsec deployment, 70 vendors participated in
the IKE interoperability testing at the most recent VPN
interoperability conference.
There are many advantages to making use of this existing support for
ISAKMP as a key management framework and IKE for the secure channel
that is our Category-1 SA of Figure 2:
a. Re-using much of the existing key management protocol promotes a
single key management framework.
b. Systems that provide network-layer protection of unicast data will
have the same market needs to provide network-layer protection for
multicast data.
c. Using the same underlying protocol will reduce both complexity and
size of the key management code.
d. Implementation can be achieved more expediently.
2.3 Overview of IKE
IKE is logically divided into two exchanges, referred to as Phase 1
and Phase 2. A Phase 1 exchange must be completed before any Phase 2
exchanges are attempted. Once the Phase 1 exchange has completed,
there is no limit to the number of Phase 2 exchanges that can take
place, and there may be simultaneous Phase 2 exchanges occurring
between IKE peers.
In Phase 1, two peers establish a bi-directional secure authenticated
channel using payloads and semantics defined in ISAKMP. Several
different authentication methods are defined for use in IKE, i.e.
manually shared keys, digital signatures, or public key encryption.
The two peers negotiate a mutually-acceptable set of cryptographic
policies, and derive keying material using the Diffie-Hellman or
public key encryption algorithms. At the end of Phase 1, the two peers
have fully authenticated each other and have exchanged adequate keying
material used to create a secure authenticated channel for Phase 1 and
Phase 2.
In Phase 2, the two peers negotiate Security Associations on behalf of
IPSEC (or other security protocols if another DOI has been defined).
IKE Phase 1 provides the following protections for any defined Phase 2
protocol:
a. Confidentiality. All messages are protected using an encryption
protocol negotiated during Phase 1.
b. Integrity. Each message contains a per-message authentication
obtained with the use of an HMAC protocol which signs hashes taken
over the Phase 2 payloads and other relevant data.
c. Replay protection. If the Phase 2 protocol uses nonces, they can
be included in the hashed data for Phase 2 messages.
d. Generation of key exchange protocol keying material. If the key
exchange protocol requires keying material to be generated, it can be
generated using the keying material exchanged during Phase 1.
2.4 Use of IKE Phase 1 as a Secure Channel
The secure channel defined by an IKE Phase 1 protects GDOI keying
material. It can directly provide confidentiality and integrity. IKE
exchanges protect against man-in-the middle, connection hijacking,
reflection and replay attacks. IKE offers some protection against
denial-of-service attacks as well. GDOI uses the IKE Phase 1 to
protect a new Phase 2 exchange called "GROUPKEY-PULL", which is
defined below.
2.4.1 IKE Phase 1 SA Payload
The IKE Phase 1 SA payload has a DOI value. That value MUST be the
GDOI DOI value as defined later in this document.
2.4.2 Use of the IKE UDP port.
GDOI does not extend IKE, but is a companion protocol to it. Therefore
the IKE Phase 1 exchange and GDOI ("phase 2") exchange SHOULD NOT use
the UDP port used by IKE. This allows a GDOI implementation to be
written independent of an IKE implementation.
3.0 GROUPKEY-PULL Exchange
The goal of the GROUPKEY-PULL exchange is to establish a Category-2
and/or Category-3 SAs at the Member for a particular Group. An IKE
Phase 1 SA protects the GROUPKEY-PULL; there may be multiple GROUPKEY-
PULL exchanges for a given Phase 1 SA. The GROUPKEY-PULL exchange
downloads the Group key encrypting key (KEK) or KEK array under the
protection of the Category 1 (IKE Phase 1) SA.
3.1 ACL-based Versus Credential-based Authorization
The GROUPKEY-PULL exchange supports two authorization models. If the
GCKS authorizes access to the Group KEK using a mechanism such as an
access control List (ACL), then a single Member identity may suffice
and the GROUPKEY-PULL exchange will not include additional credential
(CERT) and authentication data. If the GCKS uses a more sophisticated
credential-based authorization mechanism, then the Member may have a
separate identity for each Group and the GROUPKEY-PULL exchange does
this securely [STS].
In ACL-based authorization, the GCKS keeps a list of members for every
Group, and the identity of the Member is contained in the Phase 1 IKE
ID payload. The GCKS forwards the ID payloads from the Member to the
authorization application program (see Figure 3) to check the ACL
before downloading the KD payload (section 5.5) to the Member. There
are no cryptographic data passed in the GROUPKEY-PULL exchange for
ACL-based Authorization beyond SA and KD payloads, and nonces for
replay protection (see section 5.2).
Credential-based authorization uses public-key cryptography, which is
probably the most scalable authentication technology for key
management [SKEME]. In the credential-based authorization model, a
much smaller list of signing authorities will be kept by the GCKS
authorization application. The Member can use up to one CERT payload
for each KEK or KEK array it requests (through a Phase 2 ID payload).
The GCKS authenticates this identity as part of the GROUPKEY-PULL
exchange.
3.2 Messages
The GROUPKEY-PULL is an IKE Phase 2 exchange. IKE Phase 1 computes
SKEYID_a from the DH keying material exchanged in Phase 1. SKEYID_a is
the "key" in the keyed hash used in the GROUPKEY-PULL HASH payloads.
As with the IKE HASH payload generation [RFC 2409 section 5.5], each
GROUPKEY-PULL message hashes a uniquely-defined set of values. Nonces
permute the HASH and provide some protection against replay attacks.
Replay protection is important to protect the GCKS from attacks that a
key management server will attract.
The GROUPKEY-PULL uses nonces to guarantee "liveliness", or that
someone is not replaying a recent GROUPKEY-PULL message. The replay
attack is only useful in the context of the current Phase 1. If a
GROUPKEY-PULL message is replayed based on a previous IKE Phase 1, the
HASH calculation will fail due to a wrong SKEYID_a. The message will
fail processing before the nonce is ever evaluated. In order for
either peer to get the benefit of the replay protection it must
postpone as much processing as possible until it receives the message
in the protocol that proves the peer is live. For example, the
Responder MUST NOT compute the shared Diffie-Hellman number (if KE
payloads were included) or install the new SAs until it receives a
message with Nr included properly in the HASH payload.
Nonces require an additional message in the protocol exchange to
ensure that the GCKS does not add a group member until it proves
liveliness. The GROUPKEY-PULL Member-Initiator expects to find its
nonce, Ni, in the HASH of a returned message. And the GROUPKEY-PULL
GKCS Responder expects to see its nonce, Nr, in the HASH of a returned
message before providing Group-keying material as in the following
exchange.
Initiator (Member) Responder (GCKS)
------------------ ----------------
HDR*, HASH(1), Ni, ID -->
<-- HDR*, HASH(2), Nr, SA
HDR*, HASH(3) [,KE_I] -->
[,CERT] [,POP_I]
<-- HDR*, HASH(4), [KE_R,][SEQ,]
KD [,CERT] [,POP_R]
Hashes are computed as follows:
HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)
HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ][ | POP_I ])
HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ | ]
KD
[ | POP_R])
POP payload is constructed from prf(Ni | Nr)
* Protected by IKE Phase 1 SA, encryption occurs after HDR
HDR is an ISAKMP header payload that uses the Phase 1 cookies and a
message identifier (M-ID) as in IKE [RFC2409]. Note that nonces are
included in the first two exchanges, with the GCKS returning only the
SA policy payload before liveliness is proven. The HASH payloads
[RFC2409] prove that the peer has the Phase 1 secret (SKEYID_a) and
the nonce for the exchange identified by message id, M-ID. Once
liveliness is established, the last message completes the real
processing of downloading the KD payload.
In addition to the Nonce and HASH payloads, the Member Initiator
identifies the Group it wishes to join through the ISAKMP ID payload.
The GCKS Responder informs the Member of the current value of the
sequence number in the SEQ payload; the sequence number orders the
GROUPKEY-PUSH datagrams (section 4); the member MUST check to see that
the sequence number is greater than in the previous SEQ payload the
member holds for the group (if it holds any) before installing any KEK
SA. The SEQ payload MUST be present if the SA payload contains a KEK
SA payload. The GCKS Responder informs the Member of the cryptographic
policies of the Group in the SA payload, which describes the DOI, KEK
and/or TEK keying material, and authentication transforms. The SPIs
are also determined by the GCKS and downloaded in the SA payload chain
(see section 5.2). The KEK SA contains the ISAKMP cookie pair for the
Category-2 SA, which is not negotiated but downloaded. The TEK SA
contains an SPI as defined in section 5.3 of this document. The
second message downloads this SA payload. If a Category-2 SA is
defined in the SA payload, then KD will contain the KEK; if one or
more Category-3 SAs are defined in the SA payload, KD will contain the
TEKs. This is useful if there is an initial set of TEKs for the
particular Group and can obviate the need for future TEK GROUPKEY-PUSH
messages (described in section 4).
As described above, the Member may establish an identity in the
GROUPKEY-PULL exchange in an optional CERT payload that is separate
from the Phase 1 identity. When the Member Responder passes a new
CERT, a proof of possession (POP) payload accompanies it. The POP
payload demonstrates that the Member or GCKS principal has used the
very secret that authenticates that principal (i.e., the principal's
private key that corresponds to the public key used in the CERT
payload). POP_I is an ISAKMP SIG payload containing a hash of the
concatenated nonces Ni and Nr signed by the Member, when the Member
passes a CERT, signed by the Group Owner to prove its authorization.
POP_R contains the hash of the concatenated nonces Ni and Nr signed by
the GCKS, when the GCKS passes a CERT, signed by the Group owner, to
prove its authority to provide keys for a particular Group. The use
of the nonce pair for the POP payload, transformed through the IKE
prf, is designed to withstand compromise of the Category 1 (IKE Phase
1) key.
3.2.1 Perfect Forward Secrecy
If PFS is desired and the optional KE payload is used in the exchange,
then both sides compute a DH secret and use it to protect the new
keying material contained in KD. The GCKS Responder will xor the DH
secret with the KD payload and send it to the Member Initiator, which
recovers the KD by repeating this operation as in the Oakley IEXTKEY
procedure [RFC2412].
3.2.2 ISAKMP Header Initialization
Cookies are used in the ISAKMP header as a weak form of denial of
service protection. The GDOI GROUPKEY-PULL exchange uses cookies
according to ISAKMP and IKE [RFC2527, RFC2408, RFC2409].
Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0).
Major Version is 1 and Minor Version is 0 according to ISAKMP
[RFC2408, Section 3.1].
The Exchange Type has value 240 for the GDOI GROUPKEY-PULL exchange.
Flags, Message ID, and Length are according to ISAKMP [RFC2408,
Section 3.1]
3.3 Initiator Operations
Before an group member (GDOI initiator) contacts the GCKS, it must
determine the group identifier and acceptable IKE Phase 1 policy via a
unspecified method. IKE Phase 1 is initated using the GDOI DOI in the
SA payload. Once IKE Phase 1 is complete, the initator state machine
moves to the GDOI protocol.
To construct the first GDOI message the initiator chooses Ni and
creates a nonce payload, builds an identity payload including the
group identifer, and generates HASH(1).
Upon receipt of the second GDOI message, the initiator validates
HASH(2), extracts the nonce Nr, and interprets the SA payload. If the
policy in the SA payload is acceptable (e.g., the security protocol
and cryptographic protocols can be supported by the initator), the
initiator continutes the protocol.
If the group policy is to use certificates for authorization, the
initiator generates a hash of the Ni and Nr and signs it. This
becaomes the contents of the POP payload. If necessary, a CERT payload
is constructed which holds the public key corresponding to the private
key used to sign the POP payload.
The initator constructs the third GDOI message by including the CERT
and POP payloads (if needed) and creating HASH(3).
Upon receipt of the fourth GDOI messages, the initiator validates
HASH(4). If the responder sent CERT and POP_R payloads, the POP
signature is validated.
If a SEQ payload is present, the sequence number in the SEQ payload
must be checked against any previously received sequence number for
this group. If it is less than the previously received number, it
should be considered stale and ignored. (This could happen if two
GROUPKEY-PULL messages happened in parallel, and the sequence number
changed between the time the results of two GROUPKEY-PULL messages
were returned from the GCKS.
The initiator interprets the KD key packets, matching the SPIs in the
key packets to SPIs previously sent in the SA payloads identifying
particular policy. For TEK SAs, once the keys and policy are matched,
the initiator is ready to send or receive packets matching the TEK SA.
(If policy and keys had been previously received for this TEK SA, the
initator may decide instead to ignore this TEK SA in case it is
stale.) If this group has a KEK, the KEK policy and keys are marked as
ready for use.
3.4 Receiver Operations
The GCKS (responder) passively listens for incoming requests from
group members. The IKE Phase 1 authenticates the group member and sets
up the secure session with them.
Upon receipt of the first GDOI message the GCKS validates HASH(1),
extracts the Nr and group identifier in the ID payload. It verifies
that it's database contains the group information for the group
identifier.
The GCKS constructs the second GDOI message, including a nonce Nr, and
the policy for the group in an SA payload, followed by SA TEK payloads
for traffic SAs, and SA KEK policy (if the group controller will be
sending rekey messages to the group).
Upon receipt of the third GDOI message the GCKS validates HASH(3). If
the initiator sent CERT and POP_I payloads, the POP signature is
validated.
The GCKS constructs the fourth GDOI message, including the SEQ payload
(if the group controller will besending rekey messages), the KD
payload containing keys corresponding to policy previously sent in the
SA TEK and SA KEK payloads, and the CERT and POP payloads (if needed).
3.5 Use of Data Security Protocols for the Secure Channel
The IKE Phase 1 is used as a Secure Channel for the "registration" of
a Member to a Group whereby the Member authenticates itself to the
GCKS and receives keying material. In principle, a variety of means
might be used to protect the registration and pulling of keys such as
IPSEC ESP or SSL. There are advantages to that approach, moreover, in
simplicity of implementation and robustness of operation. Web
servers, for example, support SSL, which might serve as a convenient
means of securely downloading keys from the GCKS to the Member.
There is no requirement that GROUPKEY-PULL be the means by which the
GDOI SAD is initialized. It is possible that GDOI GROUPKEY-PUSH
datagrams (described below) use keying material obtained by means
other than a GROUPKEY-PULL. The GDOI, however, does not define these
other means since it is intended to be an extension to IKE for group
key management. Although the GDOI could specify a mode of operation
for GROUPKEY-PULL other than over an IKE Phase 1 SA, this is not done
in the interests of simplicity of the specification.
4.0 GROUPKEY-PUSH Message
Following the model described in [HBH00], GDOI sends control
information securely using group communications, i.e. using IP
multicast distribution of a GROUPKEY-PUSH message (which can also be
"pushed" using unicast delivery). The GROUPKEY-PUSH message replaces
a Category-2 SA KEK or KEK array, and/or creates a new Category-3 SA
(see section 1.3).
Member GCKS or Delegate
------ ----------------
<---- HDR*, SEQ, SA, KD, [CERT,] SIG
* Protected by the Category-2 SA KEK; encryption occurs after HDR
HDR is defined below. The SEQ payload is defined in the Payloads
section. The SA defines the policy (e.g. crypto suite) and attributes
(e.g. SPI) for a Category-2 and/or Category-3 SAs. The GCKS or
Delegate optionally provides a CERT payload for verification of the
SIG, which is a signature of a hash of the entire message before
encryption (including the header and excluding the SIG payload
itself). KD is the key download payload as described in the Payloads
section.
If the SA defines an LKH-style KEK array or single KEK, KD contains a
KEK or KEK array for a new Category-2 SA, which has a new cookie pair.
When the KD payload carries a new KEK SA (section 5.3), a Category-2
SA is replaced with a new SA having the same Group identifier (ID
specified in message 1 of section 3.1) and incrementing the same
sequence counter, which is initialized in message 4 of section 3.1. If
the SA defines an SA TEK payload, this informs the member that a new
Category-3 SA has been created, with keying material carried in KD
(Section 5.5).
4.1 Perfect Forward Secrecy (PFS)
The GROUPKEY-PUSH message is protected by the Group KEK though in all
cases, the GROUPKEY-PUSH message carries new key downloads, among
other information. A freshly generated secret must protect the key
download for the GROUPKEY-PUSH message to have PFS. This issue is for
further study.
4.2 Forward and Backward Access Control
Through GROUPKEY-PUSH, the GDOI supports algorithms such as LKH and
OFT that have the property of denying access to a new group key by a
member removed from the group (forward access control) and to an old
group key by a member added to the group (backward access control).
An unrelated notion to PFS, "forward access control" and "backward
access control" have been called "perfect forward security" and
"perfect backward security" in the literature [RFC2627, GSAKMP, CP00,
OFT].
4.3 Delegation of Key Management
GDOI supports delegation of GROUPKEY-PUSH datagrams through the
delegation capabilities of the PKI. However, GDOI does not explicitly
specify how the GCKS identifies delegates, but leaves this to the PKI
that is used by a particular GDOI implementation.
4.4 Use of signature keys
The GCKS SHOULD NOT use the same key to sign the SIG payload in the
GROUPKEY-PUSH message as was used for authorization in the GROUPKEY-
PULL POP payload. Doing so may contribute to an attack by a dishonest
group member where be can unwittingly cause the GCKS to sign a validly
formed GROUPKEY-PUSH message masquerading as Ni. If the same key must
be used, a different hash function SHOULD be used as a base for the
POP payload than is used as a base for the SIG payload.
4.4 ISAKMP Header Initialization
Unlike ISAKMP or IKE, the cookie pair is completely determined by the
GCKS. The cookie pair in the GDOI ISAKMP header identifies the
Category-2 SA to differentiate the secure groups managed by a GCKS.
Thus, GDOI uses the cookie fields as an SPI. Use of the cookie as an
anti-clogging token [RFC2522, RFC2408] is for further study.
Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0).
Major Version is 1 and Minor Version is 0 according to ISAKMP
[RFC2408, Section 3.1].
The Exchange Type has value 241 for the GDOI GROUPKEY-PUSH message.
Flags, Message ID, and Length are according to ISAKMP [RFC2408,
Section 3.1]
4.5 Deletion of SAs
There are times the GCKS may want to signal to receivers to delete
SAs, for example at the end of a broadcast. Deletion of keys may be
accomplished by sending an ISAKMP Delete payload as part of a GDOI
GROUPKEY-PUSH message.
5.0 Payloads and Defined Values
This document specifies use of several ISAKMP payloads, which are
defined in accordance with RFC2408. The following payloads are
extended or further specified.
Next Payload Type Value
----------------- -----
Security Association (SA) 1
Identification (ID) 5
Nonce (N) 10
Several new payload formats are required in the group security
exchanges. The Payload types for the new headers are defined in the
ISAKMP "Private USE" range.
Next Payload Type Value
----------------- -----
RESERVED 128 - 129
SA KEK Payload (SAK) 130
SA TEK Payload (SAT) 131
Key Download (KD) 132
Sequence Number (SEQ) 133
Proof of Possession (POP) 134
RESERVED 135 - 200
GDOI Private Use 201 - 255
5.1 Identification Payload
The Identification Payload is used to identify a group identity that
will later be associated with Security Associations for the group. A
group identity may map to a specific IP multicast group, or may
specify a more general identifier, such as one that represents a set
of related multicast streams.
The Identification Payload is defined as follows:
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 ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! RESERVE2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Identification Payload Format
The Identification Payload fields are defined as follows:
o Next Payload (1 octet) - Identifier for the payload type of the
next payload in the message. If the current payload is the
last in the message, this field will be zero (0).
o RESERVED (1 octet) - Unused, must be zero (0).
o Payload Length (2 octets) - Length, in octets, of the
identification data, including the generic header.
o Identification Type (1 octet) - Value describing the identity
information found in the Identification Data field.
o RESERVED2 (2 octets) - Unused, must be zero (0).
O Identification Data (variable length) - Value, as indicated by
the Identification Type.
5.1.1 Identification Type Values
The following table lists the assigned values for the Identification
Type field found in the Identification Payload.
ID Type Value
------- -----
RESERVED 0 - 10
ID_KEY_ID 11
RESERVED 12 - 127
Private Use 128 - 255
5.1.1.1 ID_KEY_ID
In the context of a GDOI ID payload, ID_KEY_ID specifies a four (4)-
octet group identifier.
5.2 Security Association Payload
The Security Association payload is defined in RFC 2408. For the GDOI,
it is used by the GCKS to assert security attributes for both
Category-2 and Category-3 SAs. In the GDOI, this payload may also be
called a GSA Payload.
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 ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! DOI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SA Attribute Next Payload ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The Security Association Payload fields are defined as follows:
o Next Payload (1 octet) - Identifies the next payload for the
GROUPKEY-PULL or the GROUPKEY-PUSH message as defined above. The next
payload MUST NOT be a SAK Payload or SAT Payload type, but the next
non-Security Association type payload.
o RESERVED (1 octet) - Must be zero.
o Payload Length (2 octets) is the octet length of the current
payload including the generic header and all TEK and KEK payloads.
o DOI (4 octets) - Is the GDOI, which is value 196 pending
assignment by the IANA.
o SA Attribute Next Payload (1 octet) - Must be either a SAK
Payload or a SAT Payload. See section 5.3.2 for a description of which
circumstances are required for each payload type to be present.
o RESERVED (2 octets) - Must be zero.
5.2.1 Payloads following the SA payload
Payloads that define specific security association attributes for the
KEK and/or TEKs used by the group MUST follow the SA payload. How many
of each payload is dependant upon the group policy. There may be zero
or one SAK Payloads, and zero or more SAT Payloads, where either one
SAK or SAT payload MUST be present.
This latitude allows for various group policies to be accommodated.
For example if the group policy does not require the use of a
Category-2 SA, the GCKS would not need to send a KEK SA payload to the
group member since all SA updates would be performed using the
Category-1 SA. Alternatively, group policy might use a Category-2 SA
but choose to download a KEK to the group member only as part of the
Category-1 SA. Therefore, the KEK policy (in the SA KEK payload) would
not be necessary as part of the Category-2 SA message SA payload.
Specifying multiple SATs allows multiple sessions to be part of the
same group and multiple streams to be associated with a session (e.g.,
video, audio, and text) but each with individual security association
policy.
5.3 SA KEK payload
The SA KEK (SAK) payload contains security attributes for the KEK
method for a Group and parameters specific to the GROUPKEY-PULL
operation.
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 ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! !
~ SPI ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! POP Algorithm ! POP Key Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ KEK Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The SAK Payload fields are defined as follows:
o Next Payload (1 octet) - Identifies the next payload for the
GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next
payload types for this message are a SAT Payload or zero to indicate
there is no SA TEK payload.
o RESERVED (1 octet) - Must be zero.
o Payload Length (2 octets) - Length of this payload, including
the KEK attributes.
o SPI (16 octets) - Security Parameter Index for the KEK. The SPI
must be the ISAKMP Header cookie pair where the first 8 octets become
the "Initiator Cookie" field of the GROUPKEY-PUSH message ISAKMP HDR,
and the second 8 octets become the "Responder Cookie" in the same HDR.
As described above, these cookies are assigned by the GCKS.
o POP Algorithm (2 octets) - The POP payload algorithm. Defined
values are specified in the following table. If no POP algorithm is
defined by the KEK policy this field must be zero.
Algorithm Type Value
-------------- -----
RESERVED 0
POP_ALG_RSA 1
POP_ALG_DSS 2
POP_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255
o POP Key Length (2 octets) - Length of the POP payload key. If no
POP algorithm is defined in the KEK policy this field must be zero.
o KEK Attributes - Contains KEK policy attributes associated with
the group. The following sections describe the possible attributes.
Any or all attributes may be optional, depending on the group policy.
5.3.1 KEK Attributes
The following attributes may be present in a SAK Payload. The
attributes must follow the format defined in ISAKMP [RFC2408] section
3.3. In the table, attributes that are defined as TV are marked as
Basic (B); attributes that are defined as TLV are marked as Variable
(V).
ID Class Value Type
-------- ----- ----
RESERVED 0
KEK_MANAGEMENT_ALGORITHM 1 B
KEK_ALGORITHM 2 B
KEK_KEY_LENGTH 3 B
KEK_KEY_LIFETIME 4 V
SIG_HASH_ALGORITHM 5 B
SIG_ALGORITHM 6 B
SIG_KEY_LENGTH 7 B
KE_OAKLEY_GROUP 10 B
The following attributes may only be included in a GROUPKEY-PULL
message: KEK_MANAGEMENT_ALGORITHM, KE_OAKLEY_GROUP.
5.3.2 KEK_MANAGEMENT_ALGORITHM
The KEK_MANAGEMENT_ALGORITHM class specifies the group KEK management
algorithm used to provide forward or backward access control (i.e.,
used to exclude group members). Defined values are specified in the
following table.
KEK Management Type Value
------------------- -----
RESERVED 0
LKH 1
OFT 2
RESERVED 3-127
Private Use 128-255
5.3.3 KEK_ALGORITHM
The KEK_ALGORITHM class specifies the encryption algorithm using with
the KEK. Defined values are specified in the following table.
Algorithm Type Value
-------------- -----
RESERVED 0
KEK_ALG_DES 1
KEK_ALG_3DES 2
KEK_ALG_TWOFISH 3
KEK_ALG_AES 4
RESERVED 5-127
Private Use 128-255
5.3.4 KEK_KEY_LENGTH
The KEK_KEY_LENGTH class specifies the KEK Algorithm key length (in
bits).
5.3.5 KEK_KEY_LIFETIME
The KEK_KEY_LIFETIME class specifies the maximum time for which the
KEK is valid. The GCKS may refresh the KEK at any time before the end
of the valid period. The value is a four (4) octet number defining a
valid time period in seconds.
5.3.6 SIG_HASH_ALGORITHM
SIG_HASH_ALGORITHM specifies the SIG payload hash algorithm. The
following tables define the algorithms for SIG_HASH_ALGORITHM.
Algorithm Type Value
-------------- -----
RESERVED 0
SIG_HASH_MD5 1
SIG_HASH_SHA1 2
RESERVED 3-127
PRIVATE USE 128-255
SIG_HASH_ALGORITHM is not required if the SIG_ALGORITHM is SIG_ALG_DSS
or SIG_ALG_ECDSS, which imply SIG_HASH_SHA1.
5.3.7 SIG_ALGORITHM
The SIG_ALGORITHM class specifies the SIG payload signature algorithm.
Defined values are specified in the following table.
Algorithm Type Value
-------------- -----
RESERVED 0
SIG_ALG_RSA 1
SIG_ALG_DSS 2
SIG_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255
5.3.8 SIG_KEY_LENGTH
The SIG_KEY_LENGTH class specifies the length of the SIG payload key.
5.3.9 KE_OAKLEY_GROUP
The KE_OAKLEY_GROUP class defines the OAKLEY Group used to compute the
PFS secret in the optional KE payload of the GDOI GROUPKEY-PULL
exchange. This attribute uses the values assigned to Group
Definitions in the IANA ipsec-registry [IPSEC-REG].
5.4 SA TEK Payload
The SA TEK (SAT) payload contains security attributes for a single TEK
SA associated with a group.
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 ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol-ID ! TEK Protocol-Specific Payload ~
+-+-+-+-+-+-+-+-+ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The SAT Payload fields are defined as follows:
o Next Payload (1 octet) - Identifies the next payload for the
GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next
payload types for this message are another SAT Payload or zero to
indicate there are no more security association attributes.
o RESERVED (1 octet) - Must be zero.
o Payload Length (2 octets) - Length of this payload, including
the TEK Protocol-Specific Payload.
o Protocol-ID (1 octet) - Value specifying the Security Protocol.
The following table defines values for the Security Protocol
Protocol ID Value
----------- -----
RESERVED 0
GDOI_PROTO_IPSEC_ESP 1
GDOI_PROTO_MESP 2
GOI_PROTO_AMESP 3
GDOI_PROTO_SRTP 4
RESERVED 5-127
PRIVATE USE 128-255
o TEK Protocol-Specific Payload (variable) - Payload which
describes the attributes specific for the Protocol-ID.
5.4.1 PROTO_IPSEC_ESP
The TEK Protocol-Specific payload for ESP is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol ! SRC ID Type ! SRC ID Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!SRC ID Data Len! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Transform ID ! SPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI ! RFC 2407 SA Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The SAT Payload fields are defined as follows:
o Protocol (1 octet) - Value describing an IP protocol ID (e.g.,
UDP/TCP). A value of zero means that the SRC Id Prot field should be
ignored.
o SRC ID Type (1 octet) - Value describing the identity
information found in the SRC Identification Data field. Defined values
are specified by the IPSEC Identification Type section in the IANA
isakmpd-registry [ISAKMP-REG].
o SRC ID Port (2 octets) - Value specifying a port associated with
the source Id. A value of zero means that the SRC ID Port field should
be ignored.
o SRC ID Data Len (1 octet) - Value specifying the length of the
SRC Identification Data field.
o SRC Identification Data (variable length) - Value, as indicated
by the SRC ID Type. Set to three bytes of zero for multiple-source
multicast groups that use a common TEK for all senders.
o DST ID Type (1 octet) - Value describing the identity
information found in the DST Identification Data field. Defined values
are specified by the IPSEC Identification Type section in the IANA
isakmpd-registry [ISAKMP-REG].
o DST ID Prot (1 octet) - Value describing an IP protocol ID
(e.g., UDP/TCP). A value of zero means that the DST Id Prot field
should be ignored.
o DST ID Port (2 octets) - Value specifying a port associated with
the source Id. A value of zero means that the DST ID Port field should
be ignored.
o DST ID Data Len (1 octet) - Value specifying the length of the
DST Identification Data field.
o DST Identification Data (variable length) - Value, as indicated
by the DST ID Type.
o Transform ID (1 octet) - Value specifying which ESP transform is
to be used. The list of valid values are defined in the IPSEC ESP
Transform Identifiers section of the IANA isakmpd-registry [ISAKMP-
REG].
o SPI (4 octets) - Security Parameter Index for ESP.
o RFC 2407 Attributes - ESP Attributes from RFC 2407 Section 4.5.
The GDOI supports all IPSEC DOI SA Attributes for PROTO_IPSEC_ESP
excluding the Group Description [RFC2407, section 4.5], which MUST NOT
be sent by a GDOI implementation and is ignored by a GDOI
implementation if received. All mandatory IPSEC DOI attributes are
mandatory in GDOI PROTO_IPSEC_ESP. The Authentication Algorithm
attribute of the IPSEC DOI is group authentication [AMESP] in GDOI.
5.4.2 Other Security Protocols
Besides ESP, GDOI should serve to establish SAs for secure groups
needed by other Security Protocols that operate at the transport,
application, and internetwork layers. These other Security Protocols,
however, are in the process of being developed or do not yet exist.
MESP and AMESP are two related secure multicast protocols being
developed under the auspices of the IRTF Secure Multicast Group
[AMESP]. These Security Protocols must be defined in the context of
the GDOI.
The following information needs to be provided for a Security Protocol
to the GDOI.
o The Protocol-ID for the particular Security Protocol
o The SPI Size
o The method of SPI generation
o The transforms, attributes and keys needed by the Security
Protocol
All Security Protocols must provide the information in the bulleted
list above to guide the GDOI implementation for that protocol. If and
when the GDOI progresses on an IETF standards track, other Security
Protocols operating within its framework will be specified in separate
standards track documents. To exemplify the structure and content of
GDOI security-protocol specifications, Appendix A contains a
specification for the SMuG Security Protocols, MESP and AMESP (see
Appendix A).
5.5 Key Download Payload
The Key Download Payload contains group keys for the Group specified
in the SA Payload. These key download payloads can have several
security attributes applied to them based upon the security policy of
the group as defined by the associated SA Payload.
When included as part of the Category-2 SA with an optional KE
payload, The Key Download Payload will be xor'ed with the new Diffie-
Hellman shared secret. The xor operation will begin at the "Number of
Key Packets" field.
If the "Number of Key Packets" is zero, the group member is expected
to delete all keys associated with the ID. This type of KD payload
will only be sent by the GCKS when a group is deleted.
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 ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Number of Key Packets ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Key Packets ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The Key Download Payload fields are defined as follows:
o Next Payload (1 octet) - Identifier for the payload type of the
next payload in the message. If the current payload is the last in
the message, then this field will be zero.
o RESERVED (1 octet) - Unused, set to zero.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o Number of Key Packets (2 octets) -- Contains the total number
of both TEK and Rekey arrays being passed in this data block.
o Key Packets
Several types of key packets are defined. Each Key Packet has
the following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! KD Type ! RESERVED ! KD Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI Size ! SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Key Packet Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
o Key Download (KD) Type (1 octet) -- Identifier for the Key Data
field of this Key Packet.
Key Download Type Value
----------------- -----
RESERVED 0
TEK 1
KEK 2
LKH 3
OFT 4
RESERVED 5-127
Private Use 128-255
"KEK" is a single key whereas LKH and OFT are arrays of key-
encrypting keys. The definition for LKH is given in the appendix.
o RESERVED (1 octet) - Unused, set to zero.
o Key Download Length (2 octets) -- Length in octets of the Key
Packet data following this field.
o SPI Size (1 octet) - Value specifying the length in octets of
the SPI as defined by the Protocol-Id.
o SPI (variable length) - Security Parameter Index which matches a
SPI previously sent in an SAK or SAT Payload.
o Key Packet Attributes (variable length) -- Contains Key
information. The format of this field is specific to the value of the
KD Type field. The following sections describe the format of each KD
Type.
5.5.1 TEK Download Type
The following attributes may be present in a SAT Payload. Exactly one
attribute matching each type sent in the SAT payload MUST be present.
The attributes must follow the format defined in ISAKMP [RFC2408]
section 3.3. In the table, attributes which are defined as TV are
marked as Basic (B); attributes which are defined as TLV are marked as
Variable (V).
TEK Class Value Type
--------- ----- ----
RESERVED 0
TEK_ALGORITHM_KEY 1 V
TEK_INTEGRITY_KEY 2 V
TEK_SOURCE_AUTH_KEY 3 V
If no TEK key packets are included in a Category-1 KD payload, the
group member can expect to receive the TEK as part of a Category-2 SA.
At least one TEK must be included in each Category-2 KD payload.
Multiple TEKs may be included if multiple streams associated with the
SA are to be rekeyed.
5.5.1.1 TEK_ALGORITHM_KEY
The TEK_ALGORITHM_KEY class declares that the encryption key for this
SPI is contained as the Key Packet Attribute. The encryption algorithm
that will use this key was specified in the SAT payload.
DES keys will consist of 64 bits (the 56 key bits with parity bit).
Triple DES keys will be be specified as 64 bits (including parity
bits) in the order that they are to be used for encryption (e.g.,
DES_KEY1, DES_KEY2, DES_KEY3).
5.5.1.2 TEK_INTEGRITY_KEY
The TEK_INTEGRITY_KEY class declares that the integrity key for this
SPI is contained as the Key Packet Attribute. The integrity algorithm
that will use this key was specified in the SAT payload. Thus GDOI
assumes that both the symmetric encryption and integrity keys are
pushed to the Member. SHA keys will consist of 160 bits, and MD5 keys
will consist of 128 bits.
5.5.1.3 TEK_SOURCE_AUTH_KEY
The TEK_SOURCE_AUTH_KEY class declares that the source authentication
key for this SPI is contained in the Key Packet Attribute. The source
authentication algorithm that will use this key was specified in the
SAT payload.
5.5.2 KEK Download Type
The following attributes may be present in a SAK Payload. Exactly one
attribute matching each type sent in the SAK payload MUST be present.
The attributes must follow the format defined in ISAKMP [RFC2408]
section 3.3. In the table, attributes which are defined as TV are
marked as Basic (B); attributes which are defined as TLV are marked as
Variable (V).
KEK Class Value Type
--------- ----- ----
RESERVED 0
KEK_ALGORITHM_KEY 1 V
SIG_ALGORITHM_KEY 2 V
If the KEK key packet is included, there MUST be only one present in
the KD payload.
5.5.2.1 KEK_ALGORITHM_KEY
The KEK_ALGORITHM_KEY class declares the encryption key for this SPI
is contained in the Key Packet Attribute. The encryption algorithm
that will use this key was specified in the SAK payload.
5.5.2.2 SIG_ALGORITHM_KEY
The SIG_ALGORITHM_KEY class declares that the public key for this SPI
is contained in the Key Packet Attribute, which may be useful when no
public key infrastructure is available. The signature algorithm that
will use this key was specified in the SAK payload.
5.5.3 LKH
The LKH key packet is comprised of attributes representing different
leaves in the LKH key tree. The format of those attributes are
described in Appendix B.
5.5.4 OFT
The OFT key packet is comprised of attributes representing different
leaves in the OFT key tree. The format of those attributes are TBD.
5.6 Sequence Number Payload
The Sequence Number Payload (SEQ) provides an anti-replay protection
for GROUPKEY-PUSH messages. Its use is similar to the Sequence Number
field defined in the IPsec ESP protocol [RFC2406].
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 ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sequence Number !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sequence Number Payload fields are defined as follows:
o Next Payload (1 octet) - Identifier for the payload type of the
next payload in the message. If the current payload is the last in
the message, then this field will be zero.
o RESERVED (1 octet) - Unused, set to zero.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o Sequence Number (4 octets) - This field contains a monotonically
increasing counter value for the group. It is initialized to zero by
the GCKS, and incremented in each subsequently-transmitted message.
Thus the first packet sent for a given Cat-2 SA will have a Sequence
Number of 1. The GDOI implementation keeps a sequence counter as an
attribute for Cat-2 SA and increments the counter upon receipt of a
GROUPKEY-PUSH message. The current value of the sequence number must
be transmitted to group members as a part of the Cat-1 SA SA payload.
A group member must keep a sliding receive window. The window must be
treated as in the ESP protocol [RFC2406] Section 3.4.3.
5.7 Proof of Possession
The Proof of Possession Payload is used as part of group membership
authorization during a GDOI exchange. The Proof of Possession Payload
is identical to an ISAKMP SIG payload. However, the usage is entirely
different as the GCKS, GCKS delegate or Member signs a prf (i.e., RFC
2409 keyed MAC) of the concatenated nonces, Ni and Nr.
5.8 Nonce
The data portion of the Nonce payload (i.e., Ni_b and Nr_b included in
the HASHs) MUST be a value between 8 and 128 bytes.
6.0 Application Scenarios
This section considers two uses of GDOI for data broadcast and video-
on-demand applications. In these applications, a "content provider"
may be a studio, such as one of the seven major U.S. movie studios, or
a regional, national or international broadcast station. There is
also a "distributor," who provides delivery to homes and business. A
"distributor" may be a cable, telco, terrestrial broadcast network or
direct-to-home satellite operator. There are more than a dozen major
network distributors in the U.S. that serve digital data to homes and
businesses. These distributors increasingly provide data services
such a multimedia stream and file delivery broadcasted to groups of
subscribers (e.g., using single source IP multicast) or delivered on
demand to a single subscriber.
A typical data broadcast may be a multicast file transfer or a stream
of a live sports event that is sent as part of a subscription or a
pay-per-view session. A typical video-on-demand application may be a
movie that is streamed or downloaded to an authenticated customer who
belongs to a subscription group, for example. The customer
authentication may use a smart card, pass phrases, network
authentication, tamper-resistant software, and other means. These
means are beyond the scope of this document though the ID and GID
payload fields convey the needed authorization information in the GDOI
Phase 1 and GROUPKEY-PULL exchanges. Each application scenario is
discussed in a separate section below.
6.1 Data Broadcast
In this scenario, a wide-area broadcaster is sending a multicast data
feed. This feed is from a live sporting event that is streamed from
the event location. This broadcaster is also the content provider who
sends the feed, which is received by authorized customers of
metropolitan-area network distributors. The network distributor also
has a GCKS that acts on its behalf and has distributed KEKs to the
Group of customers who are authorized to receive the sporting-event
feed. Our network distributor delivers the broadcast data encrypted
by the TEK, which is sent via IP Multicast in a GROUPKEY-PUSH message.
The customers who have the KEK or KEK array for the network-
distributor's Group will be able to decrypt the GROUPKEY-PUSH messages
that contain the TEK for the sporting event. In this way, the network
distributor controls access to the TEK by its customers independently
of the broadcaster, who encrypts each stream once for re-distribution
through any number of network distributors.
At the end of the data broadcast, each network distributor will have
its GCKS instruct Group members to destroy the Category-3 SA and its
TEK. This is done through a GROUPKEY-PUSH message.
6.2 Video-on-demand
In this scenario, a movie studio has mastered a movie file, and sends
it to network distributors who offer video-on-demand (VOD) service to
their customers. The content provider may choose to encrypt the file
or not. In this scenario, the network distributor has a GCKS that
acts on its behalf and has distributed KEKs to the Group of customers
who are authorized to download VOD movie files or view VOD streams.
There are many applications where the encryption needs to be unique to
the receiving device of the Group Member. So the network distributor
encrypts the file (after first decrypting it if it were previously
encrypted by the content provider). Thus the movie file is encrypted
at the point of distribution in QuickTime format, for example, in a
manner such that it can be decrypted and played by a QuickTime player.
Such a player fulfills the role of "Security Protocol" in Figure 3.
In contrast to the previous example, both the TEK and the KEK are
under the control of the network distributor owing to the need of
unique encryption of the VOD feed. The previous scenario, however,
allowed the GCKS to control the TEK and the network distributor to
control of the KEK. In some VOD applications, it may make sense for
the content provider to control the KEK and the network distributor to
control the TEK if the content provider owns the customer relationship
and the TEK is always distributed encrypted in the KEK. The use of
the KEK group secret eliminates the need for point-to-point key
establishment procedures for a 1:1 VOD session.
6.3 Summary
GDOI securely establishes keys for unicast and multicast data. As
further illustrated in the two scenaria, GDOI is suitable to manage
keys for on-demand unicast and multicast streams as well as file
download. Besides supporting 1:N and 1:1 groups, GDOI should be
effective in securing M:N applications, such as teleconferencing,
using LKH-style membership management [RFC2627]. Use of LKH-style
membership management is specified in the appendix.
7.0 Security Considerations
GDOI is a security association (SA) protocol for groups of senders and
receivers. This protocol must use best-known practices for defense
against man-in-middle, connection hijacking, replay, reflection, and
denial-of-service (DOS) attacks. Further work is needed to establish
whether this draft version of GDOI uses best-known practices for key
management.
GDOI may inherit the problems of its ancestors, ISAKMP [RFC2408] and
Internet Key Exchange [RFC2409]. Some problems remain to be addressed
in ISAKMP and IKE [FS00]. GDOI should benefit, however, from
improvements to its ancestor protocols just as it benefits from years
of experience and work embodied in those protocols. Further work is
needed to establish whether GDOI uses ISKAMP and IKE in a good way.
Of course, GDOI supports secure groups and differs from ISAKMP and IKE
in authorization, policy, SA structure, and exchanges. The SA
structure is more complex than ISAKMP and IKE. Complexity is bad for a
Security Protocol because it makes correctness analysis more difficult
than in a simpler protocol and may lead to implementation problems.
The distribution of keying material using multicast techniques,
moreover, is novel. Novelty is bad for a key management protocol
because it can contain unexpected results and problems. Further work
is needed to determine that this version of GDOI successfully employs
novel techniques such as multicast key distribution without
compromising Group security (as defined by Group policy).
8.0 IANA Considerations
8.1 ISAKMP DOI
A new ISAKMP DOI number needs to be assigned to GDOI. RFC 2407
indicates that the namespace for DOI values is in STD-2, although that
does not yet exist such as section there. The present document is in
accordance with the "Supported Security Protocols" section in
[RFC2408].
8.2 Payload Types
New ISAKMP Next Payload types need to be allocated for GDOI payload
types. No ISAKMP registry for payload types currently exists, but the
Private Use payload type namespace can be further partitioned for the
GDOI DOI. See Section 5.0 for the payloads defined in this document.
8.3 New Namespaces
The present document describes many new namespaces for use in the GDOI
payloads. Those may be found in subsections under Section 5.0. A new
GDOI registry should be created for these namespaces.
9.0 Acknowledgements
The authors thank Ran Canetti, Cathy Meadows and Andrea Colegrove.
Ran has advised the authors on secure group cryptography, which has
led to changes in the exchanges and payload definitions. Cathy
identified several problems in a previous version of this draft,
including a replay attack against the proof of possession exchange, as
well as man-in-the-middle attacks which could occur if the nonce size
was not bounded. Andrea has contributed to the group policy section
of this draft.
10.0 References
[CP00] R. Canetti, B. Pinkas, A taxonomy of multicast security issues,
http://www.ietf.org/internet-drafts/draft-irtf-smug-taxonomy-01.txt,
Work in Progress, August 2000.
[FS00] N. Ferguson and B. Schneier, A Cryptographic Evaluation of
IPsec, CounterPane, http://www.counterpane.com/ipsec.html.
[GKMARCH] M.Baugher, R.Canetti, L.Dondeti, Group Key Management
Architecture, http://search.ietf.org/internet-drafts/draft-ietf-msec-
gkmarch-00.txt, Work in Progress, June 2000.
[GSAKMP] H. Harney, A. Colegrove, E. Harder, U. Meth, R. Fleischer,
Group Secure Association Key Management Protocol,
http://search.ietf.org/internet-drafts/draft-ietf-msec-gsakmp-sec-
00.txt, June 2000, Work in Progress.
[HBH] H. Harney, M. Baugher, T. Hardjono, GKM Building Block: Group
Security Association (GSA) Definition,
http://www.ietf.org/internet-drafts/draft-irtf-smug-gkmbb-gsadef-
00.txt, Work in Progress 2000.
[HCBD] T. Hardjono, R. Canetti, M. Baugher, P. Dinsmore, Secure IP
Multicast: Problem areas, Framework, and Building Blocks,
http://www.ietf.org/internet-drafts/draft-irtf-smug-framework-00.txt,
Work in Progress 1999.
[IPSEC-REG] http://www.iana.org/assignments/ipsec-registry
[ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry
[MARKS] B. Briscoe, MARKS: Zero Side Effect Multicast Key Management
using Arbitrarily Revealed Key Sequences, Proceedings of NGC'99,
rbriscoe@bt.co.uk.
[AMESP] R. Canetti, P. Rohatgi, Pau-Chen Cheng, Multicast Data
Security Transformations: Requirements, Considerations, and Prominent
Choices, http://search.ietf.org/internet-drafts/draft-irtf-smug-data-
transforms.txt, Work In Progress, 2000.
[NAI] http://www.nai.com/media/pdf/products/tns/6_PGP_VPN_001.pdf
[OFT] D. Balenson, D. McGrew, A. Sherman, Key Management for Large
Dynamic Groups: One-Way Function Trees and Amortized Initialization,
http://www.ietf.org/internet-drafts/draft-balenson-groupkeymgmt-oft-
00.txt, February 1999, Work in Progress.
[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A
Transport Protocol for Real-Time Applications, January 1996.
[RFC2093] Harney, H., and Muckenhirn, C., "Group Key Management
Protocol (GKMP) Specification," RFC 2093, July 1997.
[RFC2094] Harney, H., and Muckenhirn, C., "Group Key Management
Protocol (GKMP) Architecture," RFC 2094, July 1997.
[RFC2327] M. Handley, V. Jacobson, SDP: Session Description Protocol,
April 1998.
[RFC2367] D. McDonald, C. Metz, B. Phan, PF_KEY Key Management API,
Version 2, July 1998.
[RFC2401] S. Kent, R. Atkinson, Security Architecture for the Internet
Protocol, November 1998
[RFC2406] S. Kent, R. Atkinson, IP Encapsulating Security Payload
(ESP), November 1998.
[RFC2407] D. Piper, The Internet IP Domain of Interpretation for
ISAKMP, November 1998.
[RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, Internet
Security Association and Key Management Protocol, November 1998.
[RFC2409] D. Harkins, D. Carrel, The Internet Key Exchange (IKE),
November, 1998.
[RFC2412] H. Orman, The OAKLEY Key Determination Protocol, November
1998.
[RFC2522] P. Karn, W. Simpson, Photuris: Session-Key Management
Protocol, March 1999.
[RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for
Multicast: Issues and Architectures, September 1998.
[SKEME] H. Krawczyk, SKEME: A Versatile Secure Key Exchange Mechanism
for Internet, ISOC Secure Networks and Distributed Systems Symposium,
San Diego, 1996.
[SRTP] R.Blom, E.Carrara, D.McGrew, M.Nasland, K.Norrman, D. Oran, The
Secure Real Time Transport Protocol, http://www.ietf.org/internet-
drafts/draft-ietf-avt-srtp-00.txt, February 2001, Work in Progress.
[STS] Diffie, P. van Oorschot, M. J. Wiener, Authentication and
Authenticated Key Exchanges, Designs, Codes and Cryptography, 2, 107-
125 (1992), Kluwer Academic Publishers.
Authors Address:
Mark Baugher
Cisco Systems
5510 SW Orchid Street
Portland, OR 97219, USA
(503) 245-4543
mbaugher@cisco.com
Thomas Hardjono
VeriSign
401 Edgewater Place, Suite 280
Wakefield, MA 01880
Tel: 781-245-6996
Email: thardjono@verisign.com
Hugh Harney
Sparta
9861 Broken Land Parkway
Columbia, MD 21046
(410) 381-9400 x203
hh@sparta.com
Brian Weis
Cisco Systems
170 W. Tasman Drive,
San Jose, CA 95134-1706, USA
(408) 526-4796
bew@cisco.com
Appendix A: Sample GDOI definitions for MESP and AMESP
Among the Security Protocols that may use the GDOI are MESP and AMESP,
which together are a protocol framework for group secrecy, group
authentication, and group source authentication [AMESP]. This
framework is to support a variety of algorithms for source
authentication and operate at the internetwork, transport or
applications layers. The MESP and AMESP protocols do not provide
source authentication; they provide a framework for source
authentication algorithms such as TESLA, which is a group source
authentication algorithm that is suitable for transport/application
layer service. Thus, if source authentication service is desired for
MESP and AMESP, then one or more group source authentication
algorithms must be defined along with MESP and AMESP. We choose to
use TESLA for this example. As mentioned above (section 5.4.2), the
GDOI definitions for group Security Protocols such as MESP and AMESP
are to have separate documents from the GDOI document. This appendix,
therefore, offers an example for Security Protocol GDOI documents.
In the model of Figure 3, the MESP/AMESP Security Protocol
implementation invokes GDOI to establish necessary security
associations for its services. The needed information is communicated
in the SA TEK payload and MESP/AMESP SA TEK attributes. These are
defined in A.1 and A.2. MESP/AMESP, moreover, specifies source-
specific information for multicast group senders so there may be
information contained in the SA TEK that is specific to a sender. The
sender-specific information is sent in a set of Extended Attributes
that are particular to the algorithm that is used. These are defined
in A.3. In both the single-sender and multiple-sender cases, the
GROUPKEY-PUSH message containing the SA TEK payload may originate from
the GCKS or from another source such as the sender or senders to the
multicast group (section 4.3).
A.1 SA TEK bindings
A GDOI implementation must initialize the SA TEK payload information
for MESP/AMESP. The reader may refer to the SA TEK payload section
5.4 for the MESP/AMESP bindings, which follow.
o SPI size is 4 octets
o SPI is a pseudo-random number created by the GCKS
A.2 MESP/AMESP SA TEK Attributes
The following attributes may be present in an MESP/AMESP SAT Payload.
These attributes are followed by attributes for the TESLA source
authentication algorithm. The attributes must follow the format
defined in ISAKMP [RFC2408] section 3.3. In the table, attributes that
are defined as TV are marked as Basic (B); attributes that are defined
as TLV are marked as Variable (V).
ID Class Value Type
-------- ----- ----
RESERVED 0
GS_ORDER 1 B
GS_PROTOCOL 2 B
GS_XFORM_TYPE 3 B
GS_XFORM_KEY_LENGTH 4 B
GS_XFORM_KEY_LIFETIME 5 B
GA_ORDER 6 B
GA_PROTOCOL 7 B
GA_TRANSFORM 8 B
SrA_ORDER 9 B
SrA_PROTOCOL 10 B
SrA_ALGORITHM 11 B
RESERVED 12-63
AUTHENTICATION ALGORITHM 64-128
PRIVATE USE 129-255
A.2.1 GS_ORDER
This is the order in which the transform is applied relative to the
other transforms. The ordering is from outer (1) to inner. If
GS_ORDER is zero then group secrecy is not employed. If it is one
(1), then GS is the first transform applied by the receiver. If
GS_ORDER is greater than GA_ORDER and SrA_ORDER, then GS is the first
transform applied by the sender. GDOI does nothing with this ordering
beyond communicating it to the MESP/AMESP implementation across the
interface shown in Figure 3 between GDOI and the Security Protocol.
A.2.2 GS_PROTOCOL
This is set to one (1) if MESP is used or two (2) if AMESP is used.
GDOI does nothing with this layering information beyond communicating
it to the MESP/AMESP implementation across the interface shown in
Figure 3 between GDOI and the Security Protocol.
A.2.3 GS_TRANSFORM
Transform Type Value
-------------- -----
RESERVED 0
GS_XFORM_DES 1
GS_XFORM_3DES 2
GS_XFORM_TWOFISH 3
GS_XFORM_AES 4
RESERVED 5-127
Private Use 128-255
A.2.4 GS_TRANSFORM_KEY_LENGTH
The length of the key in bits.
A.2.5 GS_TRANSFORM_KEY_LIFETYPE
The GS_TRANSFORM_KEY_LIFETIME specifies the maximum time for which the
key is valid. The GCKS may refresh the key at any time before the end
of the valid period. The value is a four (4) octet number defining a
valid time period in seconds.
A.2.6 GA_ORDER
See A.2.1.
A.2.7 GA_PROTOCOL
See A.2.2.
A.2.8 GA_TRANSFORM
Transform Type Value
-------------- -----
RESERVED 0
GA_XFORM_DES_MAC 1
GA_XFORM_HMAC_MD5 2
GA_XFORM_HMAC_SHA1 3
RESERVED 4-127
Private Use 128-255
A.2.9 SrA_ORDER
See A.2.1.
A.2.10 SrA_PROTOCOL
See A.2.2.
A.2.11 SrA_ALGORITHM
Algorithm Type Value
-------------- -----
RESERVED 0
SrA_TESLA 1
RESERVED 2-127
Private Use 128-255
A.3 TESLA SA TEK Attributes
The attributes for the source authentication algorithm follow the
MESP/AMESP SA TEK attributes. These are for TESLA.
ID Class Value Type
-------- ----- ----
RESERVED 0
SOURCE_ID 64 B
DIRECT_SYNCHRONIZATION 65 B
SENDERS_CERT_TYPE 66 B
SENDERS_CERT 67 V
HMAC_TYPE 68 B
KEY_CHAIN_PRF 69 B
INTERVAL_TIME 70 V
INTERVAL_NUMBER 71 V
INTERVAL_DURATION 72 V
KEY_DISCLOSURE_DELAY 73 V
KEY_CHAIN_COMMITMENT_VALUE 74 V
KEY_CHAIN_EXPIRATION_VALUE 75 V
A.3.1 SOURCE_ID
This is 32-bit number that uniquely identifies the source.
A.3.2 DIRECT_SYNCHRONIZATION
This is set to one if Direct Synchronization is desired and zero
otherwise.
A.3.3 SENDERS_CERT_TYPE
ID Class Value Type
-------- ----- ----
RESERVED 0
X.509 1 B
SPKI 2 B
PGP 3 B
RESERVED 4-127
Private Use 128-255
A.3.4 SENDERS_CERT
This is the sender's certificate.
A.3.5 HMAC_TYPE
This is the hashed message authentication code used for TESLA
messages.
HMAC Type Value
--------- -----
RESERVED 0
TESLA_HMAC_MD5 1
TESLA_HMAC_SHA1 2
TESLA_HMAC_RIPEMD160 3
RESERVED 4-127
Private Use 128-255
A.3.6 KEY_CHAIN_PRF
The PRF used for computing the key chain.
KEY_CHAIN_PRF Value
--------- -----
RESERVED 0
TESLA_PRF_MD5 1
TESLA_PRF_SHA1 2
TESLA_PRF_RIPEMD160 3
RESERVED 4-127
Private Use 128-255
A.3.7 INTERVAL_TIME
The beginning time of the current interval.
A.3.8 INTERVAL_NUMBER
The identifier of the current interval.
A.3.9 INTERVAL_DURATION
The fixed interval of time (Tint) during which a message source sends
zero or more packets may be set once for the session or may be
dynamically changed during the session. If group policy dictates that
the time interval is to be invariant, then INTERVAL_DURATION is the
number of seconds of the time interval. If INTERVAL_DURATION is not
present, then the time interval will be dynamically set by the source
authentication protocol and may vary over the lifetime of the session.
A.3.10 KEY_DISCLOSURE_DELAY
KEY_DISCLOSURE_DELAY is the number of intervals (d) before an
authentication key is disclosed. KEY_DISCLOSURE_DELAY is used if the
number of intervals must be fixed for a given session or if the sender
chooses not to vary this interval during the session. Otherwise, if
the KEY_DISCLOSURE_DELAY attribute is not present, then the key
disclosure delay may be set dynamically by the source authentication
protocol.
A.3.11 KEY_CHAIN_COMMITMENT_VALUE
The PRF value for the start of a new key chain.
A.3.12 KEY_CHAIN_EXPIRATION_VALUE
The INTERVAL_NUMBER that will be the last interval of the current key
chain.
Appendix B: LKH Data Key Download Definitions
This section contains attribute definitions used by a GCKS to transmit
a LKH KEK array to group members. These definitions are compatible
with the GSAKMP protocol [GSAKMP].
B.1 LKH Key Data (KD) Payload definitions
The following attributes are used to pass an LKH KEK array in the KD
payload. The attributes must follow the format defined in ISAKMP
[RFC2408] section 3.3. In the table, attributes which are defined as
TV are marked as Basic (B); attributes which are defined as TLV are
marked as Variable (V).
KEK Class Value Type
--------- ----- ----
RESERVED 0
KEK_LKH 1 V
If an LKH key packet is included in the KD payload, there must be only
one present.
B.1.1 KEK_LKH
This attribute consists of a header block, followed by one or more LKH
keys.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Version ! Leaf ID ! Number of ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ LKH Keys ! !
+-+-+-+-+-+-+-+-+ LKH Keys !
~ ~
+---------------------------------------------------------------+
The KEK_LKH attribute fields are defined as follows:
o LKH version (1 octet) - Contains the version of the LKH
protocol which the data is formatted in.
o Leaf ID (2 octets) -- This is the Leaf Node ID of the LKH
sequence contained in this Key Packet Data block.
o Number of LKH Keys (2 octets) -- This value is the number of
distinct LKH keys in this sequence.
Each LKH Key is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH ID ! Key Type ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Creation Date ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key expiration Date ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Handle ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- !
! !
~ Key Data ~
+---------------------------------------------------------------+
o LKH ID (2 octets) -- This is the position of this key in the
binary tree structure used by LKH.
o Key Type (1 octet) -- This is the encryption algorithm for
which this key data is to be used. This value is specified in the
Policy Token.
o Key Creation Date (4 octets) -- This is the time value of when
this key data was originally generated.
o Key Expiration Date (4 octets) -- This is the time value of
when this key is no longer valid for use.
o Key Handle (4 octets) -- This is the randomly generated value
to uniquely identify a key.
o Key Data (variable length) -- This is the actual encryption key
data, which is dependent on the Key Type algorithm for its format.
Appendix C: Sample GDOI Definitions for SRTP
As described above, Security Protocols may use GDOI to establish their
security associations (Section 5.4.2). Designers of the security
protocol should develop a draft document that describes the
information needs of their security protocol for security association
(SA) attributes and cryptographic policy. This appendix outlines a
specification for GDOI support of SRTP [SRTP].
SRTP, Secure Real Time Transport Protocol, provides authentication,
integrity, and confidentiality services for Real Time Transport
Protocol [RFC1889]. Thus SRTP is an application-layer security
protocol that operates above the TCP/IP services (sockets) interface.
SRTP communicates with GDOI using an API [we will investigate use of
PF_KEY for IPC communication]. Through the API, SRTP requests SA
establishment and GDOI updates SRTP's security association database
(SAD) for maintenance of its cryptographic context [SRTP]. The KDC or
the SRTP sender acting on behalf of the KDC provides the cryptographic
policy and other attributes through the SA TEK payload
and SRTP SA TEK attributes.
C.1 SRTP Namespace: SA TEK Bindings
A GDOI implementation must initialize the SA TEK payload information
for SRTP. The reader may refer to the SA TEK payload section 5.4 for
the description of SA TEK bindings, which follow.
o SPI size is 2 octets
o SPI the RTP 32-bit sequence number that is sent on the wire.
The receiver(s) will immediately compute the "real" SPI as the "packet
index" of SPI + rollover-counter * 2^32 and use this value with the
SSRC and Transport address to identify the SRTP cryptographic context.
Thus, a cryptographic context is identified by the RTP packet index,
the SSRC and the Transport Address. This packet index is the first
number in a sequence of RTP packets that will use the given
cryptographic context. For a given SSRC and Transport Address, a new
cryptographic context is identified by a packet index number in which
all RTP packets that equal or exceed that packet index will use the
new cryptographic context. A compliant SRTP implementation,
therefore, must compute and check the packet index to see if it
matches a new cryptographic context for a given SSRC, Transport
Address pair. At any given time, there should be at most two
cryptographic contexts available for a given SSRC, Transport Address
pair - this is how new cryptographic contexts are installed and the
key is changed for an RTP session.
C.2 SRTP Namespace: SA TEK Attributes
The following attributes are encoded according to Section 3.3, RFC
2408 [RFC2408].
ID Class Type Length
-------- ----- ------
RESERVED 0
SSRC 1 V
DESTINATION_ADDRESS 2 V
DESTINATION_RTP_PORT 3 V
DESTINATION_RTCP_PORT 4 V
ROLLOVER_COUNTER 5 V
CIPHER 6 V
CIPHER_MODE 7 V
CIPHER_KEY_LENGTH 8 V
SALT_KEY_LENGTH 9 V
AUTHENTICATION_ALGORITHM 10 B
REPLAY_WINDOW_SIZE 11 V
SRTCP_INDEX 12 V
RESERVED 13-128
C.2.1 SSRC
A 32-bit unsigned integer that identifies the SSRC of the sender.
C.2.2 DESTINATION_ADDRESS
The network address on which RTP and RTCP packets are received and
sent.
C.2.3 DESTINATION_RTP_PORT
The port number on which RTP packets are received.
C.2.4 DESTINATION_RTCP_PORT
The port number on which RTCP packets are received and sent.
C.2.5 ROLLOVER_COUNTER
The 32-bit counter that is incremented each time the sequence number
(SRTP SPI) rolls over.
C.2.6 CIPHER
The algorithm used to encipher and decipher SRTP payloads. AES is the
default.
Algorithm Type Value
-------------- -----
RESERVED 0
AES 1
RESERVED 2-127
Private Use 128-255
C.2.7 CIPHER_MODE
The mode of the cipher used to encipher and decipher SRTP payloads.
Counter_Mode_AES is the default.
Cipher Mode Value
-------------- -----
RESERVED 0
Counter_Mode_AES 1
f8_Mode_AES 2
RESERVED 3-127
Private Use 128-255
C.2.8 CIPHER_KEY_LENGTH
The length of the encryption key. 128 is the default for AES.
C.2.9 SALT_KEY_LENGTH
The length of key used for salt. 128-bit is the default for AES
Counter Mode.
C.2.10 AUTHENTICATION_ALGORITHM
The type of authentication used for SRTP.
Authentication Value
-------------- -----
RESERVED 0
UMAC 1
RESERVED 2-127
Private Use 128-255
C.2.11 WINDOW_SIZE
Replay window size defaults to 64 when not specified.
C.2.12 SRTCP_INDEX
The value of the SRTCP index which will be used in the next SRTCP
packet.
Datatracker
Report a datatracker bug
draft-ietf-msec-gdoi-02
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3547.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| Replaces | draft-irtf-smug-gdoi | ||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |