MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)
draft-ietf-msec-mikey-rsa-r-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Cullen Jennings |
2006-11-08
|
07 | (System) | Request for Early review by SECDIR Completed. Reviewer: Marcus Leech. |
2006-08-28
|
07 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2006-08-24
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
2006-08-24
|
07 | Amy Vezza | IESG has approved the document |
2006-08-24
|
07 | Amy Vezza | Closed "Approve" ballot |
2006-08-23
|
07 | Russ Housley | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Russ Housley |
2006-08-09
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-08-09
|
07 | (System) | New version available: draft-ietf-msec-mikey-rsa-r-07.txt |
2006-08-08
|
07 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings |
2006-08-08
|
07 | Cullen Jennings | [Ballot discuss] The 07 version has text that fixes all the points in my discuss. ------------------------------------------------------ It took me a long time to track through … [Ballot discuss] The 07 version has text that fixes all the points in my discuss. ------------------------------------------------------ It took me a long time to track through all this. Here is my understanding of the state of things - let me know if I have it about right. The base MIKEY draft defines both the a mandatory to implement certificate in the MIKEY messages and an optional URI that points at the certificate method. It does not state what type of URI might be used or format of data one might fetch over the implied transports. If one device is doing RSA-R with another, there is no way to discover what the other end might support. So for all practical purposes, the URI reference to a certificate is not usable. I agree it is no less unspecified that the base MIKEY, but none the less, it does not seem like two devices will not be able to use it in an interoperable way. Now this may be completely by design choice but it leads to the second part of the problem. Assuming one of the uses of this was SIP, we would need to include the certificate in the message. For 3DES level security - I'm assuming that would give us something like 800 bytes certs in DER format and with rest of the MIKEY message, the encoding into SDP, rest of SIP message etc, I suspect that it would quickly exceed the 1300 byte limit for UDP SIP requests. The conclusion that I come to is that this could not be used with SIP over UDP. So where to go from here: possibility 1) part of what I am saying above is wrong, we should educate me on it and I can clear all this possibility 2) Yep, above is about right and that is known limitations and ok. If so, lets just add an applicability statement and I will clear the discuss. possibility 3) this was not what people hand in mind, we want to use the URI indirection technique. In this case lets add some stuff to say what is mandatory to implement so that the callee knows what they can use and depend on the the other side being able to process. possibility 4) something else :-) I'm open to any suggestion. I think this document is a useful addition to MIKEY and I want it to move forward - I'm just trying to not have surprises on it. I suspect that path 2 is likely what we want to do but whatever folks think. |
2006-06-21
|
07 | Cullen Jennings | [Ballot discuss] It took me a long time to track through all this. Here is my understanding of the state of things - let me … [Ballot discuss] It took me a long time to track through all this. Here is my understanding of the state of things - let me know if I have it about right. The base MIKEY draft defines both the a mandatory to implement certificate in the MIKEY messages and an optional URI that points at the certificate method. It does not state what type of URI might be used or format of data one might fetch over the implied transports. If one device is doing RSA-R with another, there is no way to discover what the other end might support. So for all practical purposes, the URI reference to a certificate is not usable. I agree it is no less unspecified that the base MIKEY, but none the less, it does not seem like two devices will not be able to use it in an interoperable way. Now this may be completely by design choice but it leads to the second part of the problem. Assuming one of the uses of this was SIP, we would need to include the certificate in the message. For 3DES level security - I'm assuming that would give us something like 800 bytes certs in DER format and with rest of the MIKEY message, the encoding into SDP, rest of SIP message etc, I suspect that it would quickly exceed the 1300 byte limit for UDP SIP requests. The conclusion that I come to is that this could not be used with SIP over UDP. So where to go from here: possibility 1) part of what I am saying above is wrong, we should educate me on it and I can clear all this possibility 2) Yep, above is about right and that is known limitations and ok. If so, lets just add an applicability statement and I will clear the discuss. possibility 3) this was not what people hand in mind, we want to use the URI indirection technique. In this case lets add some stuff to say what is mandatory to implement so that the callee knows what they can use and depend on the the other side being able to process. possibility 4) something else :-) I'm open to any suggestion. I think this document is a useful addition to MIKEY and I want it to move forward - I'm just trying to not have surprises on it. I suspect that path 2 is likely what we want to do but whatever folks think. |
2006-06-09
|
07 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2006-06-09
|
07 | Amy Vezza | [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Amy Vezza |
2006-06-09
|
07 | (System) | Removed from agenda for telechat - 2006-06-08 |
2006-06-08
|
07 | Jon Peterson | [Ballot Position Update] Position for Jon Peterson has been changed to No Objection from Undefined by Jon Peterson |
2006-06-08
|
07 | Cullen Jennings | [Ballot discuss] The draft leaves a few details around the edge unspecified and I think we need to specify these to have interoperable devices. They … [Ballot discuss] The draft leaves a few details around the edge unspecified and I think we need to specify these to have interoperable devices. They are all fairly trivial to deal with. What URI types MUST be implemented for fetching certs. Are there any security concerns for fetching the cert. Does a devices have to implement both the embedded CERT and link to CERT approach. The document needs to discuss how large these are and any issues that might lead to when used in SDP transported over UDP. |
2006-06-08
|
07 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to Discuss from Undefined by Cullen Jennings |
2006-06-08
|
07 | Cullen Jennings | [Ballot comment] I did not fully understand how this worked in group mode - I believe it works. It just the description could use a … [Ballot comment] I did not fully understand how this worked in group mode - I believe it works. It just the description could use a bit more overview that made it easier to understand. The document would be better with an example that could be used as test vector. |
2006-06-08
|
07 | Cullen Jennings | [Ballot Position Update] New position, Undefined, has been recorded for Cullen Jennings by Cullen Jennings |
2006-06-08
|
07 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded for Ross Callon by Ross Callon |
2006-06-08
|
07 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2006-06-08
|
07 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko |
2006-06-08
|
07 | Jon Peterson | [Ballot Position Update] New position, Undefined, has been recorded for Jon Peterson by Jon Peterson |
2006-06-07
|
07 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
2006-06-07
|
07 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by Lisa Dusseault |
2006-06-07
|
07 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie |
2006-06-07
|
07 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley |
2006-06-06
|
07 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by Dan Romascanu |
2006-06-06
|
07 | Lars Eggert | [Ballot comment] Section 1.1., paragraph 0: > The MIKEY protocol [RFC3830] has three different methods for key > transport or exchange: … [Ballot comment] Section 1.1., paragraph 0: > The MIKEY protocol [RFC3830] has three different methods for key > transport or exchange: a pre-shared key mode (PSK), a public-key > (RSA) mode, and an optional Diffie-Hellman exchange (DHE) mode. In > addition, there is also an optional DH-HMAC mode [I-D.ietf-msec- > mikey-dhhmac], bringing the total number of modes to four. The > primary motivation for the MIKEY protocol design is low-latency > requirements of real-time communication, and thus all the exchanges > finish in one-half to 1 round-trip; note that this offers no room for > security parameter negotiation of the key management protocol itself. > In this document, we note that the MIKEY modes defined in RFC3830 > [RFC3830] and [I-D.ietf-msec-mikey-dhhmac] are insufficient to > address some deployment scenarious and common use cases, and propose > a new mode called MIKEY-RSA in Reverse mode, or simply as > MIKEY-RSA-R. This document updates RFC 3830 with the addition of > this new mode to that specification. NIT: s/scenarious/scenarios/ Section 3.7.3., paragraph 2: > Type | Value | Comment > ------------------------------------------------------- > Vendor ID | 0 | Vendor specific byte string > SDP IDs | 1 | List of SDP key mgmt IDs > | | (allocated for use in [KMASDP]) > CSB-ID | 3 | Responder's modified CSB-ID (group mode) Missing Reference: [KMASDP] |
2006-06-06
|
07 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert by Lars Eggert |
2006-06-06
|
07 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter |
2006-06-05
|
06 | (System) | New version available: draft-ietf-msec-mikey-rsa-r-06.txt |
2006-06-01
|
07 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund by Magnus Westerlund |
2006-05-31
|
07 | Russ Housley | [Ballot Position Update] New position, Yes, has been recorded for Russ Housley |
2006-05-31
|
07 | Russ Housley | Ballot has been issued by Russ Housley |
2006-05-31
|
07 | Russ Housley | Created "Approve" ballot |
2006-05-31
|
07 | Russ Housley | Placed on agenda for telechat - 2006-06-08 by Russ Housley |
2006-05-31
|
07 | Russ Housley | State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Russ Housley |
2006-05-31
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-05-31
|
05 | (System) | New version available: draft-ietf-msec-mikey-rsa-r-05.txt |
2006-05-23
|
07 | Russ Housley | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Russ Housley |
2006-05-19
|
07 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2006-05-09
|
07 | Yoshiko Fong | ANA Last Call Comments: Upon approval of this document, the IANA will register the below assignments in the appropriate registries located at the following: http://www.iana.org/assignments/mikey-payloads … ANA Last Call Comments: Upon approval of this document, the IANA will register the below assignments in the appropriate registries located at the following: http://www.iana.org/assignments/mikey-payloads "Error Payload namespace:" Unsupported message type ------- 13 "Common Header payload name spaces:" RSA-R I_MSG ------------- 9 RSA-R R_MSG ------------- 10 General Extensions payload name spaces: CSB-ID ----------------- 3 We understand the above assignments to be the only IANA Actions. |
2006-05-05
|
07 | Amy Vezza | Last call sent |
2006-05-05
|
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2006-05-05
|
07 | Russ Housley | State Changes to Last Call Requested from AD Evaluation by Russ Housley |
2006-05-05
|
07 | Russ Housley | Last Call was requested by Russ Housley |
2006-05-05
|
07 | (System) | Ballot writeup text was added |
2006-05-05
|
07 | (System) | Last call text was added |
2006-05-05
|
07 | (System) | Ballot approval text was added |
2006-05-05
|
07 | Russ Housley | [Note]: 'PROTO Shepherd: Ran Canetti <canetti@watson.ibm.com>' added by Russ Housley |
2006-05-05
|
07 | Russ Housley | State Changes to AD Evaluation from Publication Requested by Russ Housley |
2006-04-28
|
04 | (System) | New version available: draft-ietf-msec-mikey-rsa-r-04.txt |
2006-04-20
|
07 | Russ Housley | Draft Added by Russ Housley in state Publication Requested |
2006-03-29
|
03 | (System) | New version available: draft-ietf-msec-mikey-rsa-r-03.txt |
2006-02-01
|
02 | (System) | New version available: draft-ietf-msec-mikey-rsa-r-02.txt |
2005-10-26
|
01 | (System) | New version available: draft-ietf-msec-mikey-rsa-r-01.txt |
2005-07-08
|
00 | (System) | New version available: draft-ietf-msec-mikey-rsa-r-00.txt |