Skip to main content

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 …
[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 (like the examples in RFC 4572 do).

RFC 3280 has been obsoleted by RFC 5280, and RFC 3546 has been
obsoleted by RFC 4366.
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