| < 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/ | ||||