Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)
draft-ietf-mmusic-kmgmt-ext-15
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
15 | (System) | post-migration administrative database adjustment to the Yes position for Sam Hartman |
2012-08-22
|
15 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2005-09-19
|
15 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2005-09-16
|
15 | Amy Vezza | IESG state changed to Approved-announcement sent |
2005-09-16
|
15 | Amy Vezza | IESG has approved the document |
2005-09-16
|
15 | Amy Vezza | Closed "Approve" ballot |
2005-09-16
|
15 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2005-09-15
|
15 | Sam Hartman | [Ballot Position Update] Position for Sam Hartman has been changed to Yes from Discuss by Sam Hartman |
2005-09-05
|
15 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Undefined by Russ Housley |
2005-09-05
|
15 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to Undefined from Discuss by Russ Housley |
2005-06-14
|
15 | (System) | New version available: draft-ietf-mmusic-kmgmt-ext-15.txt |
2005-03-16
|
14 | (System) | New version available: draft-ietf-mmusic-kmgmt-ext-14.txt |
2005-02-18
|
15 | (System) | Removed from agenda for telechat - 2005-02-17 |
2005-02-17
|
15 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2005-02-17
|
15 | Harald Alvestrand | [Ballot comment] Reviewed by Lucy Lynch, Gen-ART The issues raised by Lucy are troublesome, but this stuff is hard.... |
2005-02-17
|
15 | Harald Alvestrand | [Ballot Position Update] Position for Harald Alvestrand has been changed to No Objection from Undefined by Harald Alvestrand |
2005-02-17
|
15 | Thomas Narten | [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten by Thomas Narten |
2005-02-17
|
15 | Sam Hartman | [Ballot discuss] Section 3 says that key management algorithms must be able to set up security parameters in at most one request-response message. I'm concerned … [Ballot discuss] Section 3 says that key management algorithms must be able to set up security parameters in at most one request-response message. I'm concerned about this requirement because a lot of the general purpose authentication/key agreement frameworks we've come up with support arbitrary numbers of round trips. (examples include EAP/GSSAPI/SASL). I realize that EAP is not appropriate for this application; I include it only as an example that even outside the applications space people find the ability to do multiple round trips in authentication frameworks desirable. I accept that generalizing this work to multi-round-trip mechanisms is going to be somewhat ugly and involved. I don't think it would be reasonable to request the WG to undertake that work at this time, but I'd like to leave the door open for the future. Looking both at RTSP, SIP and the OAM, it seems that it would be possible to support multi-round-trip mechanisms at least for SIP and RTSP, although it would be complicated. I propose that the requirement in section 3 be rephrased as: * At the current time, MUST be possible to execute the key management protocol in at most one request-response message exchange. Future relaxation of this requirement is possible but would introduce significant complexity for implementations supporting multi-round-trip mechanisms. Section 7 provides inconsistent advice on which protocols to offer. The use of multiple key management protocols in the same offer may open up the possibility of a bidding-down attack, as specified in Section 3.1.4. To exclude such possibility, the authentication of the protocol identifier list is used. Note though, that the security level of the authenticated protocol identifier will be as high (or low), as the "weakest" protocol. Therefore, it is discouraged to offer protocols with too different security levels. Note that it is impossible to assure the authenticity of a declined offer, since even if it comes from the true respondent, the fact that the answerer declines the offer usually means that he does not support the protocol(s) offered, and consequently cannot be expected to authenticate the response either. This means that if the Initiator is unsure of which protocol(s) the Responder supports, we RECOMMEND that the Initiator offers all acceptable protocols in a single offer. I propose fixing as follows: replace the sentece starting "Therefore, it is discouraged," with "Therefore, the offer MUST NOT contain security protocols weaker than permitted by local security policy." On my first reading, Section 6 seemed incomplete. As I can best tell, section 6 of this draft needs to specify all the same sorts of information as is included in section 5 of the SDP security descriptions draft. That's true in the general case, although MIKEY apparently includes descriptions of the SRTP glue directly; it would be useful if section 6 made this more clear. The only integrity protected attribute of the media stream is the set of key management protocols. What sort of security considerations are there associated with other sorts of modifications? For example, can I get anything by inserting the key management line from one stream into another? Does this depend on any anti-replay properties of the key management protocol? There are potentially three authenticated identities involved in a SIP session using this protocol: the SIP authenticated identity, the S/MIME authenticated idenity for protecting SIP bodies and the authenticated identity used by the key management protocol. This specification does not really give any advice on how (if at all) these identities should be related or what identities should be authorized. I'm happy to discuss this concern and try to figure out if any text is needed, but I don't understand typical interactions of these identities well enough to do so. |
2005-02-17
|
15 | Sam Hartman | [Ballot Position Update] New position, Discuss, has been recorded for Sam Hartman by Sam Hartman |
2005-02-17
|
15 | Allison Mankin | [Ballot comment] Good work getting the sdp key management documents to the finish line!! |
2005-02-17
|
15 | Allison Mankin | [Ballot Position Update] New position, Yes, has been recorded for Allison Mankin by Allison Mankin |
2005-02-17
|
15 | Harald Alvestrand | Review by Lucy Lynch, Gen-ART This draft is on the right track but has open issues. The basic mechanics of key based session security seem … Review by Lucy Lynch, Gen-ART This draft is on the right track but has open issues. The basic mechanics of key based session security seem to be in place here, but the document could really use another pass by a native english speaker - some of the constructions used are either very formal or very convoluted. (example: "The framework defined in this memo is useful when the session setup is not protected in an end-to- end fashion, but the media streams needs to be end-to-end protected, hence the security parameters (such as keys) are not wanted revealed to nor manipulated by intermediaries.") ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think I understand how this is supposed to work, but I'm not convinced that this process represents a secure exchange. Along those lines... I think I understand the "at most one request" requirement (see below) but it takes some digging to get at what a "less than one" offer would look like. 3. Usage with SDP, SIP, RTSP, and SAP * It MUST be possible to execute the key management protocol in at most one request-response message exchange. * It MUST be possible from the SIP/SDP and RTSP application, using the key management API, to receive key management data, and information of whether a message is accepted or not. I had similar issues with text about re-keying on initial offer. (Re-keying MUST be handled as a new offer) In general - the offering of multiple keys seems to introduce a lot of complexity and some security concerns - "Note that the placement of multiple key management offers in a single message has the disadvantage that the message expands and the computational workload for the offerer will increase drastically. Unless the guidelines of Section 3.1.4 are followed, multiple lines may open up bidding-down attacks. Note also that the multiple offer option has been added to optimize signaling overhead in case the Initiator knows some key (e.g. a public key) that the Responder has, but is unsure of what protocol the Responder supports. The mechanism is not intended to negotiate options within one and the same protocol." but the security section of the document recommends a single multiple key offer rather than serial attempts to find the best fit key protocol - "The use of multiple key management protocols in the same offer may open up the possibility of a bidding-down attack, as specified in Section 3.1.4. To exclude such possibility, the authentication of the protocol identifier list is used. Note though, that the security level of the authenticated protocol identifier will be as high (or low), as the "weakest" protocol. Therefore, it is discouraged to offer protocols with too different security levels. Note that it is impossible to assure the authenticity of a declined offer, since even if it comes from the true respondent, the fact that the answerer declines the offer usually means that he does not support the protocol(s) offered, and consequently cannot be expected to authenticate the response either. This means that if the Initiator is unsure of which protocol(s) the Responder supports, we RECOMMEND that the Initiator offers all acceptable protocols in a single offer. If not, this opens up the possibility for a "man-in-the-middle" (MITM) to affect the outcome of the eventually agreed upon protocol, by faking unauthenticated error messages until the Initiator eventually offers a protocol "to the liking" of the MITM. This is not really a security problem, but rather a mild form of denial of service that can be avoided by following the above recommendation. Note also that the declined offer could be result of an attacker who sits on the path and removes all the key management offers. The bidding-down attack prevention, as described above, would not work in this case (as the answerer receives no key management attribute)." This seems like a catch 22 and I'm not sure how to resolve the circular nature of the problem... idnits 1.58 tmp/draft-ietf-mmusic-kmgmt-ext-12.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html : Checking conformance with RFC 3667/3668 boilerplate... * The document seems to lack an RFC 3667 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? * The document seems to lack an RFC 3668 Section 5, para 1 IPR Disclosure Acknowledgement. * The document seems to lack an RFC 3668 Section 5, para 2 IPR Disclosure Acknowledgement. * The document seems to lack an RFC 3668 Section 5, para 3 IPR Disclosure Invitation. * There is 1 instance of lines with non-ascii characters in the document. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt : * The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? * The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? Miscellaneous warnings: - There are 9 instances of lines with hyphenated line breaks in the document. - Line 836 has weird spacing: '... client then ...' Run idnits with the --verbose option for more detailed information. |
2005-02-17
|
15 | Harald Alvestrand | [Ballot comment] Reviewed by Lucy Lynch, Gen-ART |
2005-02-17
|
15 | Harald Alvestrand | [Ballot Position Update] New position, Undefined, has been recorded for Harald Alvestrand by Harald Alvestrand |
2005-02-16
|
15 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
2005-02-16
|
15 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
2005-02-16
|
15 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2005-02-16
|
15 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman |
2005-02-16
|
15 | Russ Housley | [Ballot discuss] draft-ietf-mmusic-kmgmt-ext-13.txt and draft-ietf-mmusic-sdescriptions-09.txt are both approaches to establishing keys with SDP. However, neither document includes an applicability statement. When it it … [Ballot discuss] draft-ietf-mmusic-kmgmt-ext-13.txt and draft-ietf-mmusic-sdescriptions-09.txt are both approaches to establishing keys with SDP. However, neither document includes an applicability statement. When it it appropriate to use this technique, and when should the other one be used? Since this document uses MIKEY, I have asked the chairs of the MSEC WG to take a look at it. |
2005-02-16
|
15 | Russ Housley | [Ballot comment] I would like to see "KMID" changed to something else, like "KMPID." KMID means Keying Material IDentifier to some people, and we … [Ballot comment] I would like to see "KMID" changed to something else, like "KMPID." KMID means Keying Material IDentifier to some people, and we are naming a key management protocol with this value. |
2005-02-16
|
15 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley |
2005-02-14
|
15 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie |
2005-02-14
|
15 | Amy Vezza | State Changes to IESG Evaluation from Waiting for Writeup by Amy Vezza |
2005-02-14
|
15 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2005-02-09
|
15 | Jon Peterson | [Ballot Position Update] New position, Yes, has been recorded for Jon Peterson |
2005-02-09
|
15 | Jon Peterson | Ballot has been issued by Jon Peterson |
2005-02-09
|
15 | Jon Peterson | Created "Approve" ballot |
2005-02-09
|
15 | Jon Peterson | Placed on agenda for telechat - 2005-02-17 by Jon Peterson |
2005-02-08
|
13 | (System) | New version available: draft-ietf-mmusic-kmgmt-ext-13.txt |
2005-01-19
|
15 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2005-01-05
|
15 | Amy Vezza | Last call sent |
2005-01-05
|
15 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2005-01-05
|
15 | Jon Peterson | Last Call was requested by Jon Peterson |
2005-01-05
|
15 | Jon Peterson | State Changes to Last Call Requested from AD Evaluation::AD Followup by Jon Peterson |
2005-01-05
|
15 | (System) | Ballot writeup text was added |
2005-01-05
|
15 | (System) | Last call text was added |
2005-01-05
|
15 | (System) | Ballot approval text was added |
2004-11-23
|
15 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-11-23
|
12 | (System) | New version available: draft-ietf-mmusic-kmgmt-ext-12.txt |
2004-10-26
|
15 | Jon Peterson | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jon Peterson |
2004-09-09
|
15 | Jon Peterson | State Changes to AD Evaluation from Publication Requested by Jon Peterson |
2004-05-03
|
15 | Dinara Suleymanova | State Changes to Publication Requested from AD is watching by Dinara Suleymanova |
2004-05-03
|
15 | Dinara Suleymanova | Intended Status has been changed to Proposed Standard from None |
2004-04-09
|
11 | (System) | New version available: draft-ietf-mmusic-kmgmt-ext-11.txt |
2004-02-03
|
10 | (System) | New version available: draft-ietf-mmusic-kmgmt-ext-10.txt |
2003-10-07
|
09 | (System) | New version available: draft-ietf-mmusic-kmgmt-ext-09.txt |
2003-08-01
|
08 | (System) | New version available: draft-ietf-mmusic-kmgmt-ext-08.txt |
2003-04-07
|
15 | Jon Peterson | Shepherding AD has been changed to Peterson, Jon from Mankin, Allison |
2003-03-04
|
07 | (System) | New version available: draft-ietf-mmusic-kmgmt-ext-07.txt |
2003-02-06
|
06 | (System) | New version available: draft-ietf-mmusic-kmgmt-ext-06.txt |
2002-12-16
|
15 | Allison Mankin | Draft Added by Mankin, Allison |
2002-06-26
|
05 | (System) | New version available: draft-ietf-mmusic-kmgmt-ext-05.txt |
2002-04-25
|
04 | (System) | New version available: draft-ietf-mmusic-kmgmt-ext-04.txt |
2002-03-04
|
03 | (System) | New version available: draft-ietf-mmusic-kmgmt-ext-03.txt |
2002-02-20
|
02 | (System) | New version available: draft-ietf-mmusic-kmgmt-ext-02.txt |
2002-01-30
|
01 | (System) | New version available: draft-ietf-mmusic-kmgmt-ext-01.txt |
2001-11-12
|
00 | (System) | New version available: draft-ietf-mmusic-kmgmt-ext-00.txt |