Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)
RFC 5763
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2015-10-14
|
07 | (System) | Notify list changed from sip-chairs@ietf.org, draft-ietf-sip-dtls-srtp-framework@ietf.org to (None) |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Pasi Eronen |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Jari Arkko |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
|
2010-05-12
|
07 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
|
2010-05-12
|
07 | Cindy Morgan | [Note]: 'RFC 5763' added by Cindy Morgan |
|
2010-05-11
|
07 | (System) | RFC published |
|
2009-03-10
|
07 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
|
2009-03-10
|
07 | (System) | IANA Action state changed to No IC from In Progress |
|
2009-03-10
|
07 | (System) | IANA Action state changed to In Progress |
|
2009-03-10
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2009-03-10
|
07 | Amy Vezza | IESG has approved the document |
|
2009-03-10
|
07 | Amy Vezza | Closed "Approve" ballot |
|
2009-03-10
|
07 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
|
2009-03-09
|
07 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko |
|
2009-03-09
|
07 | (System) | New version available: draft-ietf-sip-dtls-srtp-framework-07.txt |
|
2009-03-02
|
07 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
|
2009-03-02
|
07 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
|
2009-03-02
|
07 | Pasi Eronen | [Ballot comment] |
|
2009-02-28
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2009-02-28
|
06 | (System) | New version available: draft-ietf-sip-dtls-srtp-framework-06.txt |
|
2008-11-11
|
07 | Samuel Weiler | Assignment of request for Last Call review by SECDIR to Eric Rescorla was rejected |
|
2008-11-07
|
07 | (System) | Removed from agenda for telechat - 2008-11-06 |
|
2008-11-06
|
07 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
|
2008-11-06
|
07 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
|
2008-11-06
|
07 | Jari Arkko | [Ballot discuss] I like the use of DTLS for SIP and SRTP, but unless I am missing something obvious, I think the introduction claims far … [Ballot discuss] I like the use of DTLS for SIP and SRTP, but unless I am missing something obvious, I think the introduction claims far better properties from this scheme than are actually provided. And I don't claim to be an expert in RFC 4474, so I could easily have missed something. But the document says: The goal of this work is to provide a key negotiation technique that allows encrypted communication between devices with no prior relationships. It also does not require the devices to trust every call signaling element that was involved in routing or session setup. This approach does not require any extra effort by end users and does not require deployment of certificates that are signed by a well- known certificate authority to all devices. ... The certificates can be self-signed and completely self-generated. ... The fingerprint mechanism allows one side of the connection to verify that the certificate presented in the DTLS handshake matches the certificate used by the party in the signalling. However, this requires some form of integrity protection on the signalling. S/MIME signatures, as described in RFC 3261, or SIP Identity, as described in [RFC4474] provides the highest level of security because they are not susceptible to modification by malicious intermediaries. However, even hop-by-hop security such as provided by SIPS provides some protection against modification by attackers who are not in control of on-path sigaling elements. In other words, this works without deploying certificate infrastructure and per-device certificates, as long as you assume an underlying integrity protected secure transport, which does require exactly those same things. Isn't it true that with DTLS-SRTP one of the following statements is always true, depending on how you deploy it: (1) You require certificates and global certificate infrastructure between the devices, and the approach is completely secure against attacks even from the SIP proxies, or (2) You do not require such infrastructure and there exists attacks where the SIP proxies can be MITMs in the end-to-end protocol and no one will notice. Play the part of the other party towards the first one and vice versa, do this both in SIP and in media plane. (Similar to what Suresh was worried about.) The attacks in case 2 are more complicated than those involving SDES, but really only different from them with regards to obscurity, not fundamental capability. This approach differs from previous attempts to secure media traffic where the authentication and key exchange protocol (e.g., MIKEY [RFC3830]) is piggybacked in the signaling message exchange. With DTLS-SRTP, establishing the protection of the media traffic between the endpoints is done by the media endpoints without involving the SIP/SDP communication. The document contains a lot of material on how to use 4474 etc so I feel that the above statement is unwarranted. The document also says about the motivation: Although there is already prior work in this area (e.g., Security Descriptions for SDP [RFC4568], Key Management Extensions [RFC4567] combined with MIKEY [RFC3830] for authentication and key exchange), this specification is motivated as follows: ... There is no need to reveal keys in the SIP signaling or in the SDP message exchange. Not all of the above mentioned existing schemes do that. |
|
2008-11-06
|
07 | Jari Arkko | [Ballot discuss] I like the use of DTLS for SIP and SRTP, but unless I am missing something obvious, I think the introduction claims far … [Ballot discuss] I like the use of DTLS for SIP and SRTP, but unless I am missing something obvious, I think the introduction claims far better properties from this scheme than are actually provided. The document says: The goal of this work is to provide a key negotiation technique that allows encrypted communication between devices with no prior relationships. It also does not require the devices to trust every call signaling element that was involved in routing or session setup. This approach does not require any extra effort by end users and does not require deployment of certificates that are signed by a well- known certificate authority to all devices. ... The certificates can be self-signed and completely self-generated. ... The fingerprint mechanism allows one side of the connection to verify that the certificate presented in the DTLS handshake matches the certificate used by the party in the signalling. However, this requires some form of integrity protection on the signalling. S/MIME signatures, as described in RFC 3261, or SIP Identity, as described in [RFC4474] provides the highest level of security because they are not susceptible to modification by malicious intermediaries. However, even hop-by-hop security such as provided by SIPS provides some protection against modification by attackers who are not in control of on-path sigaling elements. In other words, this works without deploying certificate infrastructure and per-device certificates, as long as you assume an underlying integrity protected secure transport, which does require exactly those same things. Isn't it true that with DTLS-SRTP one of the following statements is always true, depending on how you deploy it: (1) You require certificates and global certificate infrastructure between the devices, and the approach is completely secure against attacks even from the SIP proxies, or (2) You do not require such infrastructure and there exists attacks where the SIP proxies can be MITMs in the end-to-end protocol and no one will notice. Play the part of the other party towards the first one and vice versa, do this both in SIP and in media plane. (Similar to what Suresh was worried about.) The attacks in case 2 are more complicated than those involving SDES, but really only different from them with regards to obscurity, not fundamental capability. This approach differs from previous attempts to secure media traffic where the authentication and key exchange protocol (e.g., MIKEY [RFC3830]) is piggybacked in the signaling message exchange. With DTLS-SRTP, establishing the protection of the media traffic between the endpoints is done by the media endpoints without involving the SIP/SDP communication. The document contains a lot of material on how to use 4474 etc so I feel that the above statement is unwarranted. The document also says about the motivation: Although there is already prior work in this area (e.g., Security Descriptions for SDP [RFC4568], Key Management Extensions [RFC4567] combined with MIKEY [RFC3830] for authentication and key exchange), this specification is motivated as follows: ... There is no need to reveal keys in the SIP signaling or in the SDP message exchange. Not all of the above mentioned existing schemes do that. |
|
2008-11-06
|
07 | Jari Arkko | [Ballot discuss] I like the use of DTLS for SIP and SRTP, but unless I am missing something obvious, I think the introduction claims far … [Ballot discuss] I like the use of DTLS for SIP and SRTP, but unless I am missing something obvious, I think the introduction claims far better properties from this scheme than are actually provided. The document says: The goal of this work is to provide a key negotiation technique that allows encrypted communication between devices with no prior relationships. It also does not require the devices to trust every call signaling element that was involved in routing or session setup. This approach does not require any extra effort by end users and does not require deployment of certificates that are signed by a well- known certificate authority to all devices. ... The certificates can be self-signed and completely self-generated. ... The fingerprint mechanism allows one side of the connection to verify that the certificate presented in the DTLS handshake matches the certificate used by the party in the signalling. However, this requires some form of integrity protection on the signalling. S/MIME signatures, as described in RFC 3261, or SIP Identity, as described in [RFC4474] provides the highest level of security because they are not susceptible to modification by malicious intermediaries. However, even hop-by-hop security such as provided by SIPS provides some protection against modification by attackers who are not in control of on-path sigaling elements. In other words, this works without deploying certificate infrastructure and per-device certificates, as long as you assume an underlying integrity protected secure transport, which does require exactly those same things. Isn't it true that with DTLS-SRTP one of the following statements is always true, depending on how you deploy it: (1) You require certificates and global certificate infrastructure between the devices, and the approach is completely secure against attacks even from the SIP proxies, or (2) You do not require such infrastructure and there exists attacks where the SIP proxies can be MITMs in the end-to-end protocol and no one will notice. Play the part of the other party towards the first one and vice versa, do this both in SIP and in media plane. The attacks in case 2 are more complicated than those involving SDES, but really only different from them with regards to obscurity. This approach differs from previous attempts to secure media traffic where the authentication and key exchange protocol (e.g., MIKEY [RFC3830]) is piggybacked in the signaling message exchange. With DTLS-SRTP, establishing the protection of the media traffic between the endpoints is done by the media endpoints without involving the SIP/SDP communication. The document contains a lot of material on how to use 4474 etc so I feel that the above statement is unwarranted. The document also says about the motivation: Although there is already prior work in this area (e.g., Security Descriptions for SDP [RFC4568], Key Management Extensions [RFC4567] combined with MIKEY [RFC3830] for authentication and key exchange), this specification is motivated as follows: ... There is no need to reveal keys in the SIP signaling or in the SDP message exchange. Not all of the above mentioned existing schemes do that. |
|
2008-11-06
|
07 | Jari Arkko | [Ballot discuss] I like the use of DTLS for SIP and SRTP, but I think the introduction claims far better properties from this scheme than … [Ballot discuss] I like the use of DTLS for SIP and SRTP, but I think the introduction claims far better properties from this scheme than are actually provided. The document says: The goal of this work is to provide a key negotiation technique that allows encrypted communication between devices with no prior relationships. It also does not require the devices to trust every call signaling element that was involved in routing or session setup. This approach does not require any extra effort by end users and does not require deployment of certificates that are signed by a well- known certificate authority to all devices. ... The certificates can be self-signed and completely self-generated. ... The fingerprint mechanism allows one side of the connection to verify that the certificate presented in the DTLS handshake matches the certificate used by the party in the signalling. However, this requires some form of integrity protection on the signalling. S/MIME signatures, as described in RFC 3261, or SIP Identity, as described in [RFC4474] provides the highest level of security because they are not susceptible to modification by malicious intermediaries. However, even hop-by-hop security such as provided by SIPS provides some protection against modification by attackers who are not in control of on-path sigaling elements. In other words, this works without deploying certificate infrastructure and per-device certificates, as long as you assume an underlying integrity protected secure transport, which does require exactly those same things. Isn't it true that with DTLS-SRTP one of the following statements is always true, depending on how you deploy it: (1) You require certificates and global certificate infrastructure between the devices, and the approach is completely secure against attacks even from the SIP proxies, or (2) You do not require such infrastructure and there exists attacks where the SIP proxies can be MITMs in the end-to-end protocol and no one will notice. Play the part of the other party towards the first one and vice versa, do this both in SIP and in media plane. The attacks in case 2 are more complicated than those involving SDES, but really only different from them with regards to obscurity. This approach differs from previous attempts to secure media traffic where the authentication and key exchange protocol (e.g., MIKEY [RFC3830]) is piggybacked in the signaling message exchange. With DTLS-SRTP, establishing the protection of the media traffic between the endpoints is done by the media endpoints without involving the SIP/SDP communication. The document contains a lot of material on how to use 4474 etc so I feel that the above statement is unwarranted. |
|
2008-11-06
|
07 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
|
2008-11-06
|
07 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
|
2008-11-06
|
07 | Tim Polk | [Ballot comment] The Introduction states that: However, third party certificates MAY also be used for extra security. The limitations of that extra security should … [Ballot comment] The Introduction states that: However, third party certificates MAY also be used for extra security. The limitations of that extra security should be addressed in the security considerations. To my mind, there is some degree of "defense in depth", but using third party certificates will not address any fundamental limitations of the protocol. For example, if SIP Identity or an equivalent mechanism is not employed, third party certificates do not compensate since there is no binding between names in the certificate and the name used in the application. I am not trying to discourage use of third party certificates where available, but I don't want to see them oversold through omission. |
|
2008-11-06
|
07 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
|
2008-11-06
|
07 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to Yes from Discuss by Magnus Westerlund |
|
2008-11-06
|
07 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund |
|
2008-11-06
|
07 | Pasi Eronen | [Ballot discuss] The document needs some more text about how the responder's fingerprint is protected. In other words, how exactly the UPDATE messages and associated … [Ballot discuss] The document needs some more text about how the responder's fingerprint is protected. In other words, how exactly the UPDATE messages and associated offer/answer works together with RFC 4474 and 4916 (the UPDATE message examples in RFC 4916 have an empty message body, and thus wouldn't protect the fingerprint). Adding a second example to Section 7, showing UPDATE and RFC 4916 would make this much clearer. |
|
2008-11-06
|
07 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to Discuss from No Objection by Pasi Eronen |
|
2008-11-06
|
07 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
|
2008-11-06
|
07 | Pasi Eronen | [Ballot comment] In Section 7, "a=fingerprint: \" suggests there's a space after the colon (":"); there isn't. I'd suggest breaking the line after "SHA-1" instead … |
|
2008-11-06
|
07 | Jon Peterson | [Ballot Position Update] New position, Yes, has been recorded by Jon Peterson |
|
2008-11-05
|
07 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
|
2008-11-05
|
07 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
|
2008-11-05
|
07 | Russ Housley | [Ballot discuss] Suresh Krishnan provided a Gen-ART Review on 5-Nov-2008. While it is a bit late, I would like to see a response to … [Ballot discuss] Suresh Krishnan provided a Gen-ART Review on 5-Nov-2008. While it is a bit late, I would like to see a response to the "substantial" concern that is raised. I have not taken the time to determine if the man-in-the-middle attack is possible, and I hope the authors can quickly tell if there is a concern or not. If there is a concern, it needs to be corrected or documented in the security considerations. The entire Gen-ART review is available from: http://www.softarmor.com/rai/temp-gen-art/ draft-ietf-sip-dtls-srtp-framework-05-krishnan.txt Suresh has a "substantial" concern about Section 8.1, Responder identity. Suresh says: > > When Bob does not respond with an UPDATE message, his identity is > not integrity protected. The draft states that in such case, a > MITM attacker may tamper with the fingerprint but Bob would be > aware of this. It is not clear to me how Bob would be aware of > this. Consider the scenario where an attacker Eve (who can attack > both the signaling and media paths) has switched Bob's key > fingerprint with hers. She can receive encrypted media coming from > Alice, decrypt it for her own use and re-encrypt it for Bob and > send it to him. How will Bob detect this tampering? |
|
2008-11-05
|
07 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
|
2008-11-05
|
07 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
|
2008-11-05
|
07 | Lars Eggert | [Ballot comment] ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) Section 11., paragraph 0: > A.18. Media Security Negotation (R-NEGOTIATE) … [Ballot comment] ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) Section 11., paragraph 0: > A.18. Media Security Negotation (R-NEGOTIATE) . . . . . . . . . 32 Nit: s/Negotation/Negotiation/ Section 1., paragraph 4: > control of on-path sigaling elements. Nit: s/sigaling/signaling/ Section 6.7.2., paragraph 1: > active side MUST proceed with the DTLS handshake as appopriate even Nit: s/appopriate/appropriate/ Section 7., paragraph 3: > especialy if Identity is not in use. Note that all other signaling Nit: s/especialy/especially/ Section 8.6., paragraph 4: > In both of these cases, the assurances taht DTLS-SRTP provides in Nit: s/taht/that/ |
|
2008-11-05
|
07 | Lars Eggert | [Ballot comment] Section 11., paragraph 0: > A.18. Media Security Negotation (R-NEGOTIATE) . . . . . . . . . 32 … [Ballot comment] Section 11., paragraph 0: > A.18. Media Security Negotation (R-NEGOTIATE) . . . . . . . . . 32 Nit: s/Negotation/Negotiation/ Section 1., paragraph 4: > control of on-path sigaling elements. Nit: s/sigaling/signaling/ Section 6.7.2., paragraph 1: > active side MUST proceed with the DTLS handshake as appopriate even Nit: s/appopriate/appropriate/ Section 7., paragraph 3: > especialy if Identity is not in use. Note that all other signaling Nit: s/especialy/especially/ Section 8.6., paragraph 4: > In both of these cases, the assurances taht DTLS-SRTP provides in Nit: s/taht/that/ |
|
2008-11-05
|
07 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
|
2008-11-04
|
07 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
|
2008-10-31
|
07 | Cullen Jennings | [Note]: 'Dean Willis will act as the proto shepherd.' added by Cullen Jennings |
|
2008-10-31
|
07 | Cullen Jennings | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Cullen Jennings |
|
2008-10-31
|
07 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
|
2008-10-29
|
07 | Cullen Jennings | [Note]: 'Last Call ends Oct 31. Dean Willis will act as the proto shepherd.' added by Cullen Jennings |
|
2008-10-29
|
07 | Cullen Jennings | [Ballot Position Update] New position, Yes, has been recorded for Cullen Jennings |
|
2008-10-29
|
07 | Cullen Jennings | Ballot has been issued by Cullen Jennings |
|
2008-10-29
|
07 | Cullen Jennings | Created "Approve" ballot |
|
2008-10-29
|
07 | Cullen Jennings | Placed on agenda for telechat - 2008-11-06 by Cullen Jennings |
|
2008-10-29
|
05 | (System) | New version available: draft-ietf-sip-dtls-srtp-framework-05.txt |
|
2008-10-28
|
07 | Amanda Baber | IANA Last Call comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
|
2008-10-21
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Eric Rescorla |
|
2008-10-21
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Eric Rescorla |
|
2008-10-17
|
07 | Amy Vezza | Last call sent |
|
2008-10-17
|
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2008-10-17
|
07 | Cullen Jennings | State Changes to Last Call Requested from AD Evaluation by Cullen Jennings |
|
2008-10-17
|
07 | Cullen Jennings | Last Call was requested by Cullen Jennings |
|
2008-10-17
|
07 | (System) | Ballot writeup text was added |
|
2008-10-17
|
07 | (System) | Last call text was added |
|
2008-10-17
|
07 | (System) | Ballot approval text was added |
|
2008-10-01
|
04 | (System) | New version available: draft-ietf-sip-dtls-srtp-framework-04.txt |
|
2008-09-25
|
07 | Cullen Jennings | State Changes to AD Evaluation from Publication Requested by Cullen Jennings |
|
2008-09-25
|
07 | Cullen Jennings | [Note]: 'Dean Willis will act as the proto shepherd' added by Cullen Jennings |
|
2008-09-23
|
07 | Amy Vezza | (1.a) Who is the Document Shepherd for this document? SIP co-chair Dean Willis will act as the protocol shepherd for this document. Has the Document … (1.a) Who is the Document Shepherd for this document? SIP co-chair Dean Willis will act as the protocol shepherd for this document. Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes. The SIP working group would like to request publication of the standards-track document draft-ietf-sip-dtls-srtp-framework-03. Here's the shepherd's writeup. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Yes. The document has been closely followed in several working groups, and by several security-focused persons. Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The reviews appear to be adequate. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The reviews appear to be adequate. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There were some concerns about the level of authentication provided by this document in the face of E.164 numbers and damage to RFC 4474 Identity done by SBCs. This was extensively discussed in the WG and the compromise that was reached was that this document would include a carefully crafted description of the security properties it provided. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG as a whole understands this document and the consensus that it should move forward was reasonably strong. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? There are several outdated references that can be corrected in the RFC Editor process, but that do not otherwise impact this specification. There are also some example IP addresses that are inconsistent with current guidelines. An RFC Editor note will be provided to correct these errors. (1.h) Has the document split its references into normative and informative? Yes. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. There is a normative reference to the informational-track RFC 3325. AS this document provides the most widely-implemented mechanism for identity expression in SIP and the security provided by this specification is greatly dependent on the identity mechanism, a full understanding of the limitations of RFC 3325 is required in order to understand the impact to this specification if used with RFC 3325. 1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? This document has no IANA considerations. If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? N/A. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? N/A. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document is part of a suite of documents that specify a mechanism for keying the Secure Real-time Transport Protocol (SRTP) using Datagram Transport Layer Security (DTLS). Together, these protocols provide for in-band establishment of secure multimedia sessions without dependencies on external authentication infrastructures. This document specifies the SIP framework for DTLS-SRTP. A companion document, draft-ietf-avt-dtls-srtp, specifies the SRTP portion. Working Group Summary This document is a product of the Session Initiation Protocol (SIP) Working Group. It was developed in response to coordinated meetings held with several working groups, and in consideration of several competing specifications. Document Quality There are at least two known implementations of earlier versions of this draft, one Open Source and one commercial. Several implementors have expressed interest in implementation and deployment of the final version. Personnel The Document Shepherd for this document is Dean Willis, and the responsible Area Director is Cullen Jennings. RFC Editor Note to Accompany Pub Request: RFC Editor: Please replace all occurrences of the string "192.168.1" with "192.0.2". Please replace references to RFC 3280 with references to RFC 5280. Please replace references to RFC 3546 with references to RFC 4366. Please update any -draft references as appropriate. |
|
2008-09-23
|
07 | Amy Vezza | Draft Added by Amy Vezza in state Publication Requested |
|
2008-08-26
|
03 | (System) | New version available: draft-ietf-sip-dtls-srtp-framework-03.txt |
|
2008-07-14
|
02 | (System) | New version available: draft-ietf-sip-dtls-srtp-framework-02.txt |
|
2008-02-25
|
01 | (System) | New version available: draft-ietf-sip-dtls-srtp-framework-01.txt |
|
2007-11-12
|
00 | (System) | New version available: draft-ietf-sip-dtls-srtp-framework-00.txt |