Document: draft-ietf-mmusic-kmgmt-ext-12.txt From: Lucy E. Lynch Date: 18 januari 2005 draft-ietf-mmusic-kmgmt-ext-12.txt (Proposed Standard) Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) 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.