< draft-mattsson-mikey-ticket-04.txt   draft-mattsson-mikey-ticket-05.txt >
Network Working Group J. Mattsson Network Working Group J. Mattsson
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational T. Tian Intended status: Informational T. Tian
Expires: November 29, 2010 ZTE Expires: December 10, 2010 ZTE
May 28, 2010 June 8, 2010
MIKEY-TICKET: An Additional Mode of Key Distribution MIKEY-TICKET: Ticket Based Modes of Key Distribution
in Multimedia Internet KEYing (MIKEY) in Multimedia Internet KEYing (MIKEY)
draft-mattsson-mikey-ticket-04 draft-mattsson-mikey-ticket-05
Abstract Abstract
The Multimedia Internet KEYing (MIKEY) specification describes a key The Multimedia Internet KEYing (MIKEY) specification describes a key
management scheme for real-time applications. In this document, we management scheme for real-time applications. In this document, we
note that the currently defined MIKEY modes are insufficient to note that the currently defined MIKEY modes are insufficient to
address deployment scenarios built around a centralized key address deployment scenarios built around a centralized key
management service. Such deployments are gaining in interest. management service. Such deployments are gaining in interest.
Therefore, a set of new MIKEY modes that work well in such scenarios Therefore, a set of new MIKEY modes that work well in such scenarios
are defined. The new modes use a trusted key management service and are defined. The new modes use a trusted key management service and
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 29, 2010. This Internet-Draft will expire on December 10, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 39 skipping to change at page 4, line 39
keys, or the enveloped keys. The Responder then sends the ticket to keys, or the enveloped keys. The Responder then sends the ticket to
the KMS, which returns the appropriate keys. the KMS, which returns the appropriate keys.
MIKEY-TICKET is primarily designed to be used for media plane MIKEY-TICKET is primarily designed to be used for media plane
security in the 3GPP IP Multimedia Subsystem (IMS) [3GPP.33.328]. security in the 3GPP IP Multimedia Subsystem (IMS) [3GPP.33.328].
This implies that some extensions to the basic Kerberos concept are This implies that some extensions to the basic Kerberos concept are
needed. For instance, the Initiator may not always know the exact needed. For instance, the Initiator may not always know the exact
identity of the Responder when the communication with the key identity of the Responder when the communication with the key
management server is initiated. management server is initiated.
This document updates [RFC3830] with the MIKEY-TICKET mode. It This document defines a signaling framework enabling peers to
defines a signaling framework enabling peers to request, transfer, request, transfer, and resolve various Ticket Types using a key
and resolve various Ticket Types using a key management service. A management service. A default Ticket Type is also defined. To allow
default Ticket Type is also defined. To allow the use of 256-bit the use of 256-bit keys for users with high security requirements,
keys for users with high security requirements, additional additional encryption, authentication, and pseudo-random functions
encryption, authentication, and pseudo-random functions are defined. are defined.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Definitions of terms and notation will, unless otherwise stated, be Definitions of terms and notation will, unless otherwise stated, be
as defined in [RFC3830]. as defined in [RFC3830].
skipping to change at page 11, line 30 skipping to change at page 11, line 30
The KMS resolves the ticket. If the Responder is authorized to The KMS resolves the ticket. If the Responder is authorized to
receive the keys encoded in the ticket, the KMS retrieves the keys receive the keys encoded in the ticket, the KMS retrieves the keys
and other information. If key forking is used, the keys are modified and other information. If key forking is used, the keys are modified
(bound to the Responder) by the KMS, see Section 5.1.1. The keys and (bound to the Responder) by the KMS, see Section 5.1.1. The keys and
additional information are then sent in a RESOLVE_RESP message to the additional information are then sent in a RESOLVE_RESP message to the
Responder. The Responder then sends a TRANSFER_RESP message to the Responder. The Responder then sends a TRANSFER_RESP message to the
Initiator as verification. The TRANSFER_RESP message might include Initiator as verification. The TRANSFER_RESP message might include
information used for further key derivation. information used for further key derivation.
The use case and signaling described above is the full three exchange The use case and signaling described above is the full three round-
mode but other modes are allowed, see Section 4.1.1. Group trip mode but other modes are allowed, see Section 4.1.1. Group
communication is discussed in Section 9, Pre-Encrypted Content is communication is discussed in Section 9, Pre-Encrypted Content is
discussed in Section 8, and signaling between different KMSs is discussed in Section 8, and signaling between different KMSs is
discussed in Section 10. An alternative use case is discussed in discussed in Section 10. An alternative use case is discussed in
Appendix B. Appendix B.
The session keys are normally generated/supplied by the KMS (encoded The session keys are normally generated/supplied by the KMS (encoded
in the ticket), but in certain use cases (see Section 8) the session in the ticket), but in certain use cases (see Section 8) the session
key may be supplied by the Initiator or Responder (sent in a separate key may be supplied by the Initiator or Responder (sent in a separate
KEMAC protected with keys derived from the MPK). KEMAC protected with keys derived from the MPK).
skipping to change at page 15, line 4 skipping to change at page 15, line 4
derivation specification). The MAC SHALL cover the entire derivation specification). The MAC SHALL cover the entire
REQUEST_INIT_PSK message as well as the identities of the involved REQUEST_INIT_PSK message as well as the identities of the involved
parties (see Section 5.5 for the exact definition). parties (see Section 5.5 for the exact definition).
4.2.1.3. Components of the REQUEST_INIT_PK Message 4.2.1.3. Components of the REQUEST_INIT_PK Message
The identity IDRi and certificate CERTi SHOULD be included, but they The identity IDRi and certificate CERTi SHOULD be included, but they
MAY be left out when it can be expected that the KMS can obtain the MAY be left out when it can be expected that the KMS can obtain the
certificate in some other manner. If a certificate chain is to be certificate in some other manner. If a certificate chain is to be
provided, each certificate in the chain SHOULD be included in a provided, each certificate in the chain SHOULD be included in a
separate CERT payload. separate CERT payload. The Initiator's certificate MUST come first.
Each following certificate MUST directly certify the one preceding
it.
PKE contains the encrypted envelope key: PKE = E(PKkms, env_key). It PKE contains the encrypted envelope key: PKE = E(PKkms, env_key). It
is encrypted using the KMS's public key (PKkms). If the KMS is encrypted using the KMS's public key (PKkms). If the KMS
possesses several public keys, the Initiator can indicate the key possesses several public keys, the Initiator can indicate the key
used in the CHASH payload. used in the CHASH payload.
SIGNi is a signature covering the entire REQUEST_INIT_PK message, SIGNi is a signature covering the entire REQUEST_INIT_PK message,
using the Initiator's signature key (see Section 5.5 for the exact using the Initiator's signature key (see Section 5.5 for the exact
definition). definition).
skipping to change at page 21, line 20 skipping to change at page 21, line 20
shared by the Responder and the KMS. The MAC SHALL cover the entire shared by the Responder and the KMS. The MAC SHALL cover the entire
RESOLVE_INIT_PSK message as well as the identities of the involved RESOLVE_INIT_PSK message as well as the identities of the involved
parties (see Section 5.5 for the exact definition). parties (see Section 5.5 for the exact definition).
4.2.3.3. Components of the RESOLVE_INIT_PK Message 4.2.3.3. Components of the RESOLVE_INIT_PK Message
The identity IDRr and certificate CERTr SHOULD be included, but they The identity IDRr and certificate CERTr SHOULD be included, but they
MAY be left out when it can be expected that the KMS can obtain the MAY be left out when it can be expected that the KMS can obtain the
certificate in some other manner. If a certificate chain is to be certificate in some other manner. If a certificate chain is to be
provided, each certificate in the chain SHOULD be included in a provided, each certificate in the chain SHOULD be included in a
separate CERT payload. separate CERT payload. The Responder's certificate MUST come first.
Each following certificate MUST directly certify the one preceding
it.
PKE contains the encrypted envelope key: PKE = E(PKkms, env_key). It PKE contains the encrypted envelope key: PKE = E(PKkms, env_key). It
is encrypted using PKkms. If the KMS possesses several public keys, is encrypted using PKkms. If the KMS possesses several public keys,
the Responder can indicate the key used in the CHASH payload. the Responder can indicate the key used in the CHASH payload.
SIGNr is a signature covering the entire RESOLVE_INIT_PK message, SIGNr is a signature covering the entire RESOLVE_INIT_PK message,
using the Responder's signature key (see Section 5.5 for the exact using the Responder's signature key (see Section 5.5 for the exact
definition). definition).
4.2.3.4. Processing the RESOLVE_INIT Message 4.2.3.4. Processing the RESOLVE_INIT Message
skipping to change at page 27, line 25 skipping to change at page 27, line 25
TRANSFER_INIT = ----> TRANSFER_INIT = ---->
HDR, T, [IDRr], [IDRi], HDR, T, [IDRr], [IDRi],
{SP}, [KEMAC], V < - - TRANSFER_RESP = {SP}, [KEMAC], V < - - TRANSFER_RESP =
HDR, T, [IDRi], HDR, T, [IDRi],
{SP}, [KEMAC], V {SP}, [KEMAC], V
The new message exchange MUST use the same CSB ID as the initial The new message exchange MUST use the same CSB ID as the initial
exchange, but MUST use new timestamps. The crypto sessions exchange, but MUST use new timestamps. The crypto sessions
negotiation (#CS field, CS ID map info field, and SP payloads) are negotiation (#CS field, CS ID map info field, and SP payloads) are
handled as is the initial exchange. In the TRANSFER_INIT message the handled as in the initial exchange. In the TRANSFER_INIT message the
V flag SHALL be used to indicate whether a response message is V flag SHALL be used to indicate whether a response message is
expected or not. The ticket and other static payloads that were expected or not. The ticket and other static payloads that were
provided in the initial exchange MUST NOT be included. New RANDs provided in the initial exchange MUST NOT be included. New RANDs
MUST NOT be included in the message exchange (the RANDs will only MUST NOT be included in the message exchange (the RANDs will only
have effect in the initial exchange). The reason that new RANDs have effect in the initial exchange). The reason that new RANDs
SHALL NOT be used is that if several TGKs are used, the peers would SHALL NOT be used is that if several TGKs are used, the peers would
need to keep track of which RANDs to use for each TGK. This adds need to keep track of which RANDs to use for each TGK. This adds
unnecessary complexity. Both messages SHALL be protected with the unnecessary complexity. Both messages SHALL be protected with the
same keys (derived from MPKi or MPKr') that protected the last same keys (derived from MPKi or MPKr') that protected the last
message (TRANSFER_INIT or TRANSFER_RESP) in the initial exchange. message (TRANSFER_INIT or TRANSFER_RESP) in the initial exchange.
 End of changes. 9 change blocks. 
16 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/