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 |