Skip to main content

MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)
draft-mattsson-mikey-ticket-05

Revision differences

Document history

Date Rev. By Action
2015-10-14
05 (System) Notify list changed from john.mattsson@ericsson.com, tian.tian1@zte.com.cn, draft-mattsson-mikey-ticket@ietf.org to (None)
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Robert Sparks
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Adrian Farrel
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2011-03-24
05 Cindy Morgan State changed to RFC Published from RFC Ed Queue.
2011-03-24
05 Cindy Morgan [Note]: 'RFC 6043' added
2011-03-21
05 (System) RFC published
2010-09-13
05 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-09-13
05 (System) IANA Action state changed to Waiting on RFC Editor from RFC-Ed-Ack
2010-09-13
05 (System) IANA Action state changed to RFC-Ed-Ack from In Progress
2010-09-13
05 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-09-10
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-09-10
05 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-09-07
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-09-07
05 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-09-03
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-08-31
05 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2010-08-30
05 (System) IANA Action state changed to In Progress
2010-08-30
05 Amy Vezza IESG state changed to Approved-announcement sent
2010-08-30
05 Amy Vezza IESG has approved the document
2010-08-30
05 Amy Vezza Closed "Approve" ballot
2010-08-30
05 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2010-08-30
05 Robert Sparks [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss by Robert Sparks
2010-06-17
05 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel
2010-06-08
05 (System) New version available: draft-mattsson-mikey-ticket-05.txt
2010-06-05
05 Adrian Farrel [Ballot discuss]
I have reduced the content of my Discuss

To me it looks like this doesn't actually update 3830.
2010-06-05
05 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to Discuss from No Objection by Adrian Farrel
2010-06-05
05 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel
2010-05-28
05 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2010-05-28
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-05-28
04 (System) New version available: draft-mattsson-mikey-ticket-04.txt
2010-05-06
05 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2010-05-06
05 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2010-05-06
05 Adrian Farrel
[Ballot discuss]
I share the concerns raised by Russ and Robert.
Furthermore, I don't understand why this document is Informational yet includes RFC 2119 language …
[Ballot discuss]
I share the concerns raised by Russ and Robert.
Furthermore, I don't understand why this document is Informational yet includes RFC 2119 language that seems to provide normative behavior descriptions.
To me it looks like this should be Standards Track, but that it possibly doesn't actually update 3830.
(Not my area of expertise, however, so I will be guided by the Security folk.)
2010-05-06
05 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel
2010-05-06
05 Robert Sparks
[Ballot comment]
This document doesn't really benefit from mentioning SIP at the level it does. I realize much of the text describing SIP forking is …
[Ballot comment]
This document doesn't really benefit from mentioning SIP at the level it does. I realize much of the text describing SIP forking is carried forward from earlier work, but as motivation it is incomplete and misleading (it doesn't address early media (where its possible to have multiple active branches exchanging media for long periods of time), overly simplifies how the set of recipients is formed (especially missing that it elements can be added based on early responses (recursive redirection)), and downplays the possibility of multiple 200 OKs).

It would be sufficient to note that this mechanism is useful for any system where the initiators transfer could be delivered to arbitrarily many potential recipients (stressing more strongly that the set may change, even after the KDC has started servicing resolutions).
2010-05-06
05 Robert Sparks
[Ballot discuss]
This is a discuss-discuss that I will clear after a short conversation with the IESG, there is nothing for the authors to do …
[Ballot discuss]
This is a discuss-discuss that I will clear after a short conversation with the IESG, there is nothing for the authors to do with this discuss at this time (please consider the comment below however).

I think Russ' question is an important one, and am uncomfortable that this didn't go through the WG. Is this the way you expect this extension point to be exercised often?
2010-05-06
05 Robert Sparks [Ballot Position Update] New position, Discuss, has been recorded by Robert Sparks
2010-05-06
05 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant
2010-05-06
05 Gonzalo Camarillo
[Ballot comment]
draft-mattsson-mikey-ticket-03.txt

In the Abstract:

OLD:
...required by many existing applications, e.g. so called forking where the...

NEW:
...used by many existing applications (e.g., …
[Ballot comment]
draft-mattsson-mikey-ticket-03.txt

In the Abstract:

OLD:
...required by many existing applications, e.g. so called forking where the...

NEW:
...used by many existing applications (e.g., forking) where the...


Introduction:

You may want to split the following sentence into two:

  "A high level outline of MIKEY-TICKET as defined herein is that
  the Initiator requests keys and a ticket from the KMS and sends the
  ticket containing a reference to the keys, or the enveloped keys, to
  the Responder."


Section 3 describes SIP forking and explains some of its associated
problems. Section 12.4 contains the same description. This description
could be expanded and clarified a bit because there are really several
problems here. One scenario is when an INVITE sent to a user reaches
that user on multiple devices, all of which are owned by that user. A
different problem appears when mixing forking and retargeting. The
INVITE will be delivered to different users. Section 4.2 of RFC 5479
describes these two scenarios. Of course, the security implications
are different depending on the scenario. A third scenario is the one
covered in the current text with the somebody@company.example
example. I would change that URI to something like
IT-support@example.com instead so that it is clearer what type of
service we are talking about.

Note that I am OK with the conclusion that the respondents should not
share the same private key. I am just suggesting to describe the
issues related to SIP forking properly. Also, it may be good to
mention up front in Section 3 that in addition to being able to meet
the requirement just described, the mechanism specified in this
document also supports group key management.

Section 7 says:

  "If SDP or RTSP is not used, it has to be
  defined how MIKEY is transported over the transport protocol in
  question (e.g.  HTTP)."

What does this mean? Who has to define that?
2010-05-06
05 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo
2010-05-06
05 Gonzalo Camarillo
[Ballot comment]
draft-mattsson-mikey-ticket-03.txt

In the Abstract:

OLD:
...required by many existing applications, e.g. so called forking where the...

NEW:
...used by many existing applications (e.g., …
[Ballot comment]
draft-mattsson-mikey-ticket-03.txt

In the Abstract:

OLD:
...required by many existing applications, e.g. so called forking where the...

NEW:
...used by many existing applications (e.g., forking) where the...


Introduction:

You may want to split the following sentence into two:

  "A high level outline of MIKEY-TICKET as defined herein is that
  the Initiator requests keys and a ticket from the KMS and sends the
  ticket containing a reference to the keys, or the enveloped keys, to
  the Responder."


Section 3 describes SIP forking and explains some of its associated
problems. Section 12.4 contains the same description. This description
could be expanded and clarified a bit because there are really several
problems here. One scenario is when an INVITE sent to a user reaches
that user on multiple devices, all of which are owned by that user. A
different problem appears when mixing forking and retargeting. The
INVITE will be delivered to different users. Section 4.2 of RFC 5479
describes these two scenarios. Of course, the security implications
are different depending on the scenario. A third scenario is the one
covered in the current text with the somebody@company.example
example. I would change that URI to something like
IT-support@example.com instead so that it is clearer what type of
service we are talking about.

Note that I am OK with the conclusion that the respondents should not
share the same private key. I am just suggesting to describe the
issues related to SIP forking properly. Also, it may be good to
mention up front in Section 3 that in addition to being able to meet
the requirement just described, the mechanism specified in this
document also supports group key management
2010-05-05
05 Russ Housley [Ballot discuss]
Discuss-Discuss: Do we want this (once approved) Informational RFC to
  update Standards Track RFC 3830?
2010-05-05
05 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2010-05-05
05 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2010-05-05
05 (System) State Changes to IESG Evaluation from IESG Evaluation - Defer by system
2010-04-23
05 (System) Removed from agenda for telechat - 2010-04-22
2010-04-22
05 Robert Sparks State Changes to IESG Evaluation - Defer from IESG Evaluation by Robert Sparks
2010-04-22
05 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss by Sean Turner
2010-04-22
05 Sean Turner
[Ballot comment]
1) Sec 2.2 & 3: According to RFC 5280: CA should be Certification Authority not Certificate Authority

2) Sec 4.1: r/The Ticket …
[Ballot comment]
1) Sec 2.2 & 3: According to RFC 5280: CA should be Certification Authority not Certificate Authority

2) Sec 4.1: r/The Ticket Request exchange is optional/The Ticket Request exchange is OPTIONAL

3) Sec 4.1: r/The Ticket Resolve exchange is optional/The Ticket Resolve exchange is OPTIONAL

4) Sec 4.2.3.1: Does the trust anchor also get distributed in a cert payload?

5) Sec 5.2: What happens if a KEYMAC payload is included when the Ticket Policy flag says it shouldn't be?

6) Sec 6.3: I'm not sure it's appropriate to have a requirement in a NOTE.  Can this just be made a new paragraph?

7) Sec 7: r/If SDP or RTSP is not used, it has to be defined how MIKEY is transported over the transport protocol in question (e.g.  HTTP)./If SDP or RTSP is not used, the transport protocol (e.g. HTTP) needs to be defined.
2010-04-22
05 Sean Turner
[Ballot discuss]
Is Appendix A a normative part of the specification or is it informative?  I think you should clearly state which it is in …
[Ballot discuss]
Is Appendix A a normative part of the specification or is it informative?  I think you should clearly state which it is in the first sentence because it was not clear to me that I'd have to implement it if I wanted to be conformant.
2010-04-22
05 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded by Sean Turner
2010-04-21
05 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2010-04-20
05 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre
2010-04-19
05 Tim Polk State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Tim Polk
2010-04-19
05 Tim Polk [Ballot Position Update] New position, Yes, has been recorded for Tim Polk
2010-04-19
05 Tim Polk Ballot has been issued by Tim Polk
2010-04-19
05 Tim Polk Created "Approve" ballot
2010-04-15
05 Samuel Weiler Request for Telechat review by SECDIR is assigned to Tobias Gondrom
2010-04-15
05 Samuel Weiler Request for Telechat review by SECDIR is assigned to Tobias Gondrom
2010-04-12
05 Tim Polk Placed on agenda for telechat - 2010-04-22 by Tim Polk
2010-04-12
05 Tim Polk Note field has been cleared by Tim Polk
2010-04-09
05 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Tobias Gondrom.
2010-04-08
03 (System) New version available: draft-mattsson-mikey-ticket-03.txt
2010-04-07
05 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2010-04-06
05 Amanda Baber
IANA questions/comments:

Upon approval of this document, IANA will perform the following actions
in the "Multimedia Internet KEYing (Mikey) Payload Name Spaces"
registry at
http://www.iana.org/assignments/mikey-payloads …
IANA questions/comments:

Upon approval of this document, IANA will perform the following actions
in the "Multimedia Internet KEYing (Mikey) Payload Name Spaces"
registry at
http://www.iana.org/assignments/mikey-payloads

Note to authors: there are some questions for the authors. Please see
"QUESTION" below.


ACTION 1:

in sub-registry "Common Header payload name spaces", add the following
assignments:

Value Data Type Reference
----- ---------------- ---------
TBD1 REQUEST_INIT_PSK [RFC-mattsson-mikey-ticket-02]
TBD2 REQUEST_INIT_PK [RFC-mattsson-mikey-ticket-02]
TBD3 REQUEST_RESP [RFC-mattsson-mikey-ticket-02]
TBD4 TRANSFER_INIT [RFC-mattsson-mikey-ticket-02]
TBD5 TRANSFER_RESP [RFC-mattsson-mikey-ticket-02]
TBD6 RESOLVE_INIT_PSK [RFC-mattsson-mikey-ticket-02]
TBD7 RESOLVE_INIT_PK [RFC-mattsson-mikey-ticket-02]
TBD8 RESOLVE_RESP [RFC-mattsson-mikey-ticket-02]

QUESTION: Table 6.1 has a "Comment" column, but the sub-registry does
not have one. Therefore, no comment will be added to the registry.
Please confirm that this is ok.


ACTION 2:

in sub-registry "Next Payload", add the following assignments:

Value Next Payload Section Reference
----- ------------ ------- ---------
TBD9 TR 6.4 [RFC-mattsson-mikey-ticket-02]
TBD10 IDR 6.6 [RFC-mattsson-mikey-ticket-02]
TBD11 RANDR 6.8 [RFC-mattsson-mikey-ticket-02]
TBD12 TP 6.11 [RFC-mattsson-mikey-ticket-02]
TBD13 TICKET 6.11 [RFC-mattsson-mikey-ticket-02]


ACTION 3:

in sub-registry "PRF Func", add the following assignment:

Value PRF func Section Reference
----- ---------------- ------- ---------
TBD14 PRF-HMAC-SHA-256 6.1 [RFC-mattsson-mikey-ticket-02]


ACTION 4:

in sub-registry "CS ID map type", add the following assignment:

Value CS ID map type Reference
----- -------------- ---------
TBD15 GENERIC-ID [RFC-mattsson-mikey-ticket-02]


ACTION 5:

in sub-registry "Key data transport payload name spaces", add the
following assignments:

Value Encr alg Section Reference
----- ---------- ------- ---------
TBD16 AES-CM-256 6.2 [RFC-mattsson-mikey-ticket-02]

QUESTION: Table 6.5 has a "Comment" column, but the sub-registry does
not have one. Therefore, no comment will be added to the registry.
Please confirm that this is ok.


ACTION 6:

in sub-registry "MAC alg", add the following assignments:

Value MAC alg Section Reference
----- ---------------- ------- ---------
TBD17 HMAC-SHA-256-256 6.2 [RFC-mattsson-mikey-ticket-02]

QUESTION: Table 6.6 has a "Length(bits)" column, but the sub-registry
does not have one. Therefore, no length will be added to the registry.
Please confirm that this is ok.


ACTION 7:

in sub-registry "Timestamp payload name spaces", add the following
assignments:

Value TS Type Reference
----- ---------- ---------
TBD18 NTP-UTC-32 [RFC-mattsson-mikey-ticket-02]

QUESTION: Table 6.7 has a "Length of TS value" column, but the
sub-registry does not. As such, the length will not be added to the
registry. Please confirm this is ok.


ACTION 8:

in sub-registry "ID payload and Certificate payload name spaces", add
the following assignments:

Value ID Type Reference
----- ----------- ---------
TBD19 Byte string [RFC-mattsson-mikey-ticket-02]


ACTION 9:

in sub-registry "Cert Hash payload name spaces", add the following
assignments:

Value Hash func Reference
----- --------- ---------
TBD20 SHA-256 [RFC-mattsson-mikey-ticket-02]

QUESTION: Table 6.11 has a "Hash Length (bits)" column, but the
sub-registry does not. As such, the length will not be added to the
registry. Please confirm that this is ok.


ACTION 10:

in sub-registry "Error payload name spaces", add the following assignments:

Value Error no Reference
----- -------------- ---------
TBD21 Invalid TICKET [RFC-mattsson-mikey-ticket-02]
TBD22 Invalid TPpar [RFC-mattsson-mikey-ticket-02]

QUESTION: Table 6.13 has a "Comments" column, but the sub-registry does
not. As such, comments will not be added to the registry. Please
confirm that this is ok.


ACTION 11:

in sub-registry "Key Data payload name spaces", add the following
assignments:

Value Type Reference
----- --------- ---------
TBD23 GTGK [RFC-mattsson-mikey-ticket-02]
TBD24 GTGK+SALT [RFC-mattsson-mikey-ticket-02]
TBD25 MPK [RFC-mattsson-mikey-ticket-02]

QUESTION: Table 6.14 has a "Comments" column, but the sub-registry does
not. As such, comments will not be added to the registry. Please
confirm that this is ok.


ACTION 12:

create a new sub-registry "TS Role", with the following initial content:

Registration Procedures:
1-239: Specification Required
240-254: Private Use

Value range: 8 bit unsigned integer

Value TS Role Reference
------- ------------------------------ --------
0 Reserved [RFC-mattsson-mikey-ticket-02]
1 Time of issue (TRi) [RFC-mattsson-mikey-ticket-02]
2 Start of validity period (TRs) [RFC-mattsson-mikey-ticket-02]
3 End of validity period (TRe) [RFC-mattsson-mikey-ticket-02]
4 Reykeying interval (TRr) [RFC-mattsson-mikey-ticket-02]
5-239 Unassigned
240-254 Private Use [RFC-mattsson-mikey-ticket-02]
255 Reserved [RFC-mattsson-mikey-ticket-02]


ACTION 13:

create a new sub-registry "ID Role", with the following initial content:

Registration Procedures:
1-239 Specification Required
240-254 Private Use

Value range: 8 bit unsigned integer

Value ID Role Reference
------- ----------------------- ----------
0 Reserved [RFC-mattsson-mikey-ticket-02]
1 Initiator (IDRi) [RFC-mattsson-mikey-ticket-02]
2 Responder (IDRr) [RFC-mattsson-mikey-ticket-02]
3 KMS (IDRkms) [RFC-mattsson-mikey-ticket-02]
4 Pre-Shared Key (IDRpsk) [RFC-mattsson-mikey-ticket-02]
5 Application (IDRapp) [RFC-mattsson-mikey-ticket-02]
6-239 Unassigned
240-254 Private Use [RFC-mattsson-mikey-ticket-02]
255 Reserved [RFC-mattsson-mikey-ticket-02]


ACTION 14:

create a new sub-registry "Rand Role", with the following initial content:

Registration Procedures:
1-239 Specification Required
240-254 Private Use

Value range: 8 bit unsigned integer

Value RAND Role Reference
----- ------------------ -----------------
0 Reserved [RFC-mattsson-mikey-ticket-02]
1 Initiator (RANDRi) [RFC-mattsson-mikey-ticket-02]
2 Responder (RANDRr) [RFC-mattsson-mikey-ticket-02]
3 KMS (RANDRkms) [RFC-mattsson-mikey-ticket-02]
4-239 Unassigned
240-254 Private Use [RFC-mattsson-mikey-ticket-02]
255 Reserved [RFC-mattsson-mikey-ticket-02]


ACTION 15:

create a new sub-registry "Ticket Type", with the following initial content:

Registration Procedures:
1-61439 Specification Required
61440-65534 Private Use

Value range: 16 bit unsigned integer

Value Ticket Type Reference
----------- ----------------- -----------------
0 Reserved [RFC-mattsson-mikey-ticket-02]
1 MIKEY base ticket [RFC-mattsson-mikey-ticket-02]
2 3GPP base ticket [RFC-mattsson-mikey-ticket-02]
3-61439 Unassigned
61440-65534 Private Use [RFC-mattsson-mikey-ticket-02]
65535 Reserved [RFC-mattsson-mikey-ticket-02]
2010-03-15
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Tobias Gondrom
2010-03-15
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Tobias Gondrom
2010-03-10
05 Amy Vezza Last call sent
2010-03-10
05 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2010-03-10
05 Tim Polk Last Call was requested by Tim Polk
2010-03-10
05 (System) Ballot writeup text was added
2010-03-10
05 (System) Last call text was added
2010-03-10
05 (System) Ballot approval text was added
2010-03-10
05 Tim Polk State Changes to Last Call Requested from Publication Requested by Tim Polk
2010-03-10
05 Tim Polk Draft Added by Tim Polk in state Publication Requested
2010-03-07
02 (System) New version available: draft-mattsson-mikey-ticket-02.txt
2010-01-30
01 (System) New version available: draft-mattsson-mikey-ticket-01.txt
2009-11-05
(System) Posted related IPR disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-mattsson-mikey-ticket-00
2009-10-19
00 (System) New version available: draft-mattsson-mikey-ticket-00.txt