DTLS-SRTP Handling in SIP Back-to-Back User Agents
RFC 7879
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-05-31 |
12 | (System) | RFC published |
2016-05-31 |
12 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-05-23 |
12 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-05-06 |
12 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2016-04-18 |
12 | (System) | RFC Editor state changed to EDIT |
2016-04-18 |
12 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2016-04-18 |
12 | (System) | Announcement was received by RFC Editor |
2016-04-18 |
12 | (System) | IANA Action state changed to No IC from In Progress |
2016-04-18 |
12 | (System) | IANA Action state changed to In Progress |
2016-04-18 |
12 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2016-04-18 |
12 | Amy Vezza | IESG has approved the document |
2016-04-18 |
12 | Amy Vezza | Closed "Approve" ballot |
2016-04-18 |
12 | Amy Vezza | Ballot approval text was generated |
2016-04-18 |
12 | Amy Vezza | Ballot writeup was changed |
2016-04-18 |
12 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2016-04-12 |
12 | Alissa Cooper | [Ballot comment] Thanks for handling my DISCUSS points. |
2016-04-12 |
12 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
2016-04-04 |
12 | Ram R | New version available: draft-ietf-straw-b2bua-dtls-srtp-12.txt |
2016-03-07 |
11 | Ram R | New version available: draft-ietf-straw-b2bua-dtls-srtp-11.txt |
2016-03-01 |
10 | Stephen Farrell | [Ballot comment] Thanks for addressing my discuss points. You still have a reference to 3.1.1 in section 5.1.2, which I guess should now be a … [Ballot comment] Thanks for addressing my discuss points. You still have a reference to 3.1.1 in section 5.1.2, which I guess should now be a reference to 5.1.1. I didn't check if there are any other similar internal references that need fixing. |
2016-03-01 |
10 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2016-02-28 |
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-02-28 |
10 | Ram R | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2016-02-28 |
10 | Ram R | New version available: draft-ietf-straw-b2bua-dtls-srtp-10.txt |
2015-12-03 |
09 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for AD Go-Ahead |
2015-12-03 |
09 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-12-02 |
09 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2015-12-02 |
09 | Joel Jaeggli | [Ballot comment] Dan Romascanu performed the opsdir review |
2015-12-02 |
09 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-12-02 |
09 | Barry Leiba | [Ballot comment] I support at least some of Alissa's and Stephen's DISCUSS points. In particular, I'm not fully in agreement with Alissa on her point … [Ballot comment] I support at least some of Alissa's and Stephen's DISCUSS points. In particular, I'm not fully in agreement with Alissa on her point 1: We do sometimes (and should) make normative statements about how protocols should work and should be used, even with knowledge that those statements may (will) be ignored. Sometimes it's to keep the protocol tight; sometimes it's to provide a lever ("The IETF has a standard that says that what you're doing is wrong!"). Because of that, Alissa's point 2 is particularly important: We have to stop the general practice of watering down normative statement in protocols as a way of mollifying people who don't like them. If the right thing is to say "MUST do X", we should not say "SHOULD do X" because we know that some implementations don't and won't do X. In particular, here, if there's any value in this, it's necessary to be strict and clear to expose that value. |
2015-12-02 |
09 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-12-02 |
09 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2015-12-02 |
09 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-12-02 |
09 | Cindy Morgan | Changed consensus to Yes from Unknown |
2015-12-02 |
09 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-12-02 |
09 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-12-01 |
09 | Stephen Farrell | [Ballot discuss] I wonder if you've gotten wrapped around the axle here knowing that we won't standardise a (D)TLS MitM, but yet trying to describe … [Ballot discuss] I wonder if you've gotten wrapped around the axle here knowing that we won't standardise a (D)TLS MitM, but yet trying to describe things that basically are often deployed as MitMs. Anyway, while I do agree with Alissa's discuss, I also have some additional points to raise, some of which I think came up when we had some mail exchanges about an earlier version of this draft back in January of this year. (1) Alissa is correct that the unqualified SHOULD NOT "terminate" DTLS is insufficient, but in addition to her call for qualification of that, (or I guess moving to a MUST NOT,) I would like to chat about the consequences should one (for whatever reason) ignore that SHOULD NOT. Whether or not this discuss point is worth talking about depends on how Alissa's discuss on this is resolved. It seems to me (as I said back in January) that keeping the SHOULD NOT would mean that any UA that is able to inter-operate with a B2BUA that does "terminate" DTLS (because it fits with whatever qualifiers you end up adding to the SHOULD NOT) can never ever be confident of the identity of any DTLS peer (since it has code that lets the call happen regardless of the DTLS-layer peer identity). I can't see how that wouldn't make the Internet worse, hence the discuss. (2) In the introduction you say "B2BUAs terminating DTLS-SRTP session are outside the scope of this document." yet if you keep the SHOULD NOT and don't move that to a MUST NOT (which was an option we discussed back in Jan, I assume the WG didn't like that?), then you are in fact including those are within the scope of this document and therefore you would need to specify how to "terminate" a DTLS or DTLS-SRTP session when one is a B2BUA but yet respect RFC2804. I just can't see how one might do that to be honest. (3) 3.1.2 says: "There are two types of media-aware relays, those that merely inspect the RTP headers and unencrypted portions of RTCP packets, and those that inspect and modify the RTP headers and unencrypted portions of RTCP packets." Logically, those are not the only options, as one can modify the encrypted portions too. (Hopefully resulting in the integrity checking causing the packets to be dropped.) I think this particular lack of clarity does raise to the level of a DISCUSS as it's crucial for this document to be clear about not standardising a MitM. ("Sins of omission" are probably not a good idea here:-) (4) 3.1.2.2 says: "This security and privacy problem can be mitigated by having different keys for protecting RTP header integrity and encrypting the RTP payload. For example, the approach discussed in [I-D.jones-perc-private-media-reqts] can be used." I have two issues with that. First, where is having different keys documented? If only in the draft referenced, then what is the status of that? And secondly, doesn't perc require a KMS to exist? In which case I can't see how this specification works for calls between UAs (via a B2BUA) where there is no KMS. I think there are both security and interop (and hence also process) issues with what you're saying here. (5) 3.2 says: "the ClientHello message from a B2BUA (acting as DTLS client)" I don't see how a B2BUA can send it's own ClientHello (as opposed to forwarding a UA's) unless it is a MitM. Since we do not standardise MitM (cf. RFC2804) this text must be wrong or out of place? |
2015-12-01 |
09 | Stephen Farrell | [Ballot comment] - I don't see what Figure2 is trying to tell me, though the preceding text is clear enough. I'd recommend maybe dropping that … [Ballot comment] - I don't see what Figure2 is trying to tell me, though the preceding text is clear enough. I'd recommend maybe dropping that figure or else making it a full ladder diagram of (most of) the messages involved. - There's a repetition of the "SHOULD NOT" problem that affects my point (1) above and Alissa's discuss points in the security considerations when you say "Attempting to cover media-aware relay modifying RTP headers and media termination scenarios involving secure sessions (like DTLS-SRTP) will inevitably lead to the B2BUA acting as a man-in-the-middle, and hence it is RECOMMENDED that B2BUAs do not terminate DTLS-SRTP session." - As with Alissa, I think the reliance on 4474, especially if that is not deployed, is odd. It would be bad if that were read as encouragement to not check DTLS client/server certs unless one implements 4474. (But this is covered in Alissa's discuss so is just a comment here.) |
2015-12-01 |
09 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2015-12-01 |
09 | Kathleen Moriarty | [Ballot comment] I like the idea of documenting the methods used for MiTM to provide ways to avoid that in practice, but support Alyssa'a discuss … [Ballot comment] I like the idea of documenting the methods used for MiTM to provide ways to avoid that in practice, but support Alyssa'a discuss points to make this point more clear (purpose of this documentation) and her concerns about what happens in actual implementations. I'd like to hear more on whether this should be standards track or informational as well and will follow along with her discuss thread. |
2015-12-01 |
09 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from No Record |
2015-11-30 |
09 | Alissa Cooper | [Ballot discuss] (1) I have a fairly fundamental concern about this document that I'd like to discuss. My impression is that most B2BUAs in the … [Ballot discuss] (1) I have a fairly fundamental concern about this document that I'd like to discuss. My impression is that most B2BUAs in the market today that handle DTLS-SRTP do so with the explicit purpose of accessing the media. That is, if I need a box that doesn't access the media I use a SIP proxy, and if I need one that does access it I use a B2BUA. I realize that there are more flavors of B2BUA defined in RFC 7092, but in terms of how real SBCs work, it seems to me that they break DTLS-SRTP intentionally if they do so at all. If that's the case, the question then arises about the value of writing down normative recommendations that are more than likely to be ignored. Perhaps this document would have made more sense as informational, offering a non-normative explanation of what a B2BUA should do if it does not want to break e2e security. Even as an informational document it's still not obvious to me that there is much at all to say here for media-aware B2BUAs that isn't entirely reductive -- "don't terminate DTLS-SRTP if you don't want to break DTLS-SRTP" -- but at least as an informational document it wouldn't be suggesting normative requirements that are out of sync with real deployments. Could you articulate the reasons why someone would build a B2BUA that follows the recommendations in this draft? I note that the draft says nothing about using a TURN server as a media relay, which seems like it would be more common than using a B2BUA for the same purpose. Aren't B2BUAs typically deployed *because* they are media-aware? (2) Taking into account the above comment, I think 3.1.2.1 and 3.1.2.2 are problematic. 3.1.2.1 creates a normative SHOULD NOT-level requirement for inspection B2BUAs without explaining what the exception cases are, and 3.1.2.2 creates no normative requirements for modification B2BUAs. It's not even clear to me why the distinction is being drawn between the two kinds of B2BUAs if the bottom line is that in both cases the recommendation is to not terminate DTLS-SRTP. But this brings us back to the above comment. The problem here seems to be that what the WG and the IETF would want to say here is that B2BUAs MUST NOT terminate DTLS-SRTP to man-in-the-middle the media, but that is what B2BUAs generally do, so instead the text waffles and the recommendations are watered down and unclear. (3) The characterization of the RFC 4474 mechanism seems to contradict the way the mechanism is actually specified. The 4474 mechanism was designed such that intermediaries would be able to provide signatures on behalf of users (e.g., see RFC 4474 Section 3, "This specification allows either a user agent or a proxy server to provide identity services and to verify identities ... in the initial use of this mechanism, it is likely that intermediaries will instantiate the authentication service role"). So the claim that terminating DTLS-SRTP would cause 4474 identity and integrity checks to fail isn't true, because an SBC can decrypt and re-sign the request itself. A B2BUA that bridges two administrative domains can check the validity of the signature in the domain on on side as authorization to form a new signature that is valid in the domain in the other side. The fact that user-provided identity assertions are not guaranteed to persist end-to-end is one key reason for the ongoing work in the STIR WG. The work there and elsewhere shows that it's fairly widely acknowledged that 4474 has not seen the deployment that was hoped for when it was specified. Making its use a normative requirement here again seems out of sync with deployment reality. I would encourage you to review draft-ietf-stir-rfc4474bis and reconsider what security mechanism should form the basis of the recommendations in this draft. |
2015-11-30 |
09 | Alissa Cooper | [Ballot comment] Section 3.1.1: Is there anything new being specified here that isn't already specified in other SIP documents? Section 3.2: Is this saying anything … [Ballot comment] Section 3.1.1: Is there anything new being specified here that isn't already specified in other SIP documents? Section 3.2: Is this saying anything that RFC 5763 doesn't already say? |
2015-11-30 |
09 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2015-11-30 |
09 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Record from Yes |
2015-11-30 |
09 | Kathleen Moriarty | [Ballot comment] Thank you for your work on this draft to reduce the use of Man in the Middle methods. |
2015-11-30 |
09 | Kathleen Moriarty | Ballot comment text updated for Kathleen Moriarty |
2015-11-30 |
09 | Kathleen Moriarty | [Ballot comment] Thank you for your work on this draft to reduce Man in the Middle attacks. |
2015-11-30 |
09 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2015-11-30 |
09 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-11-30 |
09 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-11-30 |
09 | Francis Dupont | Request for Last Call review by GENART Completed: Ready. Reviewer: Francis Dupont. |
2015-11-26 |
09 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Paul Wouters. |
2015-11-25 |
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2015-11-25 |
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2015-11-22 |
09 | Ram R | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-11-22 |
09 | Ram R | New version available: draft-ietf-straw-b2bua-dtls-srtp-09.txt |
2015-11-19 |
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Dan Romascanu. |
2015-11-18 |
08 | Francis Dupont | Request for Last Call review by GENART Completed: Ready. Reviewer: Francis Dupont. |
2015-11-17 |
08 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2015-11-12 |
08 | Ben Campbell | Placed on agenda for telechat - 2015-12-03 |
2015-11-12 |
08 | Ben Campbell | Ballot has been issued |
2015-11-12 |
08 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2015-11-12 |
08 | Ben Campbell | Created "Approve" ballot |
2015-11-12 |
08 | Ben Campbell | Ballot approval text was generated |
2015-11-10 |
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2015-11-10 |
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2015-11-02 |
08 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-straw-b2bua-dtls-srtp-08, which is currently in Last Call, and has the following comments: We understand that this document doesn't … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-straw-b2bua-dtls-srtp-08, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object. If this assessment is not accurate, please respond as soon as possible. |
2015-11-02 |
08 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: "IETF-Announce" <ietf-announce@ietf.org> CC: draft-ietf-straw-b2bua-dtls-srtp@ietf.org, ben@nostrum.com, christer.holmberg@ericsson.com, straw-chairs@ietf.org, straw@ietf.org Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> … The following Last Call announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: "IETF-Announce" <ietf-announce@ietf.org> CC: draft-ietf-straw-b2bua-dtls-srtp@ietf.org, ben@nostrum.com, christer.holmberg@ericsson.com, straw-chairs@ietf.org, straw@ietf.org Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: EXTENSION of Last Call: <draft-ietf-straw-b2bua-dtls-srtp-08.txt> (DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)) to Proposed Standard The IESG has received a request from the Sip Traversal Required for Applications to Work WG (straw) to consider the following document: - 'DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)' <draft-ietf-straw-b2bua-dtls-srtp-08.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-11-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) often act on the media plane, rather than just on the signaling path. This document describes the behavior such B2BUAs can adhere to when acting on the media plane that uses an Secure Real-time Transport (SRTP) security context set up with the Datagram Transport Layer Security (DTLS) protocol. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-dtls-srtp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-dtls-srtp/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-11-02 |
08 | Amy Vezza | Last call announcement was changed |
2015-10-29 |
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Paul Wouters |
2015-10-29 |
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Paul Wouters |
2015-10-28 |
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2015-10-28 |
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2015-10-27 |
08 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2015-10-27 |
08 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-straw-b2bua-dtls-srtp-08, which is currently in Last Call, and has the following comments: We understand that this document doesn't … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-straw-b2bua-dtls-srtp-08, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object. If this assessment is not accurate, please respond as soon as possible. |
2015-10-27 |
08 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-10-27 |
08 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: "IETF-Announce" <ietf-announce@ietf.org> CC: draft-ietf-straw-b2bua-dtls-srtp@ietf.org, ben@nostrum.com, christer.holmberg@ericsson.com, straw-chairs@ietf.org, straw@ietf.org Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> … The following Last Call announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: "IETF-Announce" <ietf-announce@ietf.org> CC: draft-ietf-straw-b2bua-dtls-srtp@ietf.org, ben@nostrum.com, christer.holmberg@ericsson.com, straw-chairs@ietf.org, straw@ietf.org Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-straw-b2bua-dtls-srtp-08.txt> (DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)) to Proposed Standard The IESG has received a request from the Sip Traversal Required for Applications to Work WG (straw) to consider the following document: - 'DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)' <draft-ietf-straw-b2bua-dtls-srtp-08.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-11-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) often act on the media plane, rather than just on the signaling path. This document describes the behavior such B2BUAs can adhere to when acting on the media plane that uses an Secure Real-time Transport (SRTP) security context set up with the Datagram Transport Layer Security (DTLS) protocol. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-dtls-srtp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-dtls-srtp/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-10-27 |
08 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-10-27 |
08 | Amy Vezza | Last call announcement was changed |
2015-10-26 |
08 | Ben Campbell | Last call was requested |
2015-10-26 |
08 | Ben Campbell | IESG state changed to Last Call Requested from AD Evaluation |
2015-10-26 |
08 | Ben Campbell | Last call announcement was generated |
2015-10-26 |
08 | Ben Campbell | Last call announcement was generated |
2015-10-26 |
08 | Ben Campbell | Ballot writeup was changed |
2015-10-26 |
08 | Ben Campbell | Ballot writeup was generated |
2015-10-26 |
08 | Ben Campbell | Ballot approval text was generated |
2015-10-19 |
08 | Ram R | New version available: draft-ietf-straw-b2bua-dtls-srtp-08.txt |
2015-10-14 |
07 | (System) | Notify list changed from draft-ietf-straw-b2bua-dtls-srtp@ietf.org, draft-ietf-straw-b2bua-dtls-srtp.ad@ietf.org, draft-ietf-straw-b2bua-dtls-srtp.shepherd@ietf.org, straw-chairs@ietf.org, christer.holmberg@ericsson.com to (None) |
2015-10-05 |
07 | Ben Campbell | Hi, This is my AD Evaluation of draft-ietf-straw-b2bua-dtls-srtp-07. I think at least some of this needs to be resolved prior to IETF last call. Thanks! … Hi, This is my AD Evaluation of draft-ietf-straw-b2bua-dtls-srtp-07. I think at least some of this needs to be resolved prior to IETF last call. Thanks! Ben. ------------------- Comments and Questions ====================== - There's a marked lack of mention of B2BUAs that inspect or modify media content. I realize that this draft does not seek to enable that particular elephant-in-the-room. Is it worth mentioning them as out of scope? Does this draft intend to make them illegal for SRTP protected sessions with it's proscription about terminating dtls? - 1.2: "The following sections describe the behavior B2BUAs MUST follow in order to avoid any impact to end-to-end DTLS-SRTP sessions." Does that need the MUST, since the described behavior also uses normative language? Also, is this really a matter of things the b2bUA MUST do, or a set of other things it MUST NOT do? Also, this paragraph could use some elaboration. There are a number of use cases that violate this(e.g. 3GPP's e2ea security model). This doesn't seem to forbid those, since they don't purport to support e2e crypto--is that the intent? Can "impact" be more precise? -3.1.1, 3rd paragraph from end: "the B2BUA SHOULD be prepared to receive DTLS, STUN and media on the ports it advertised to Bob in the INVITE request. " What are the consequences if it's not prepared to do so? Also, this is a timing issue, right? So shouldn't is say something like "SHOULD be prepared immediately prepared" or "should be prepared to receive...before the it receives the SIP response"? -3.1.1, 2nd to last paragraph: Is the a general proscription, or is it limited to cases where 4474bis is in use? Also, I think the 4474bis reference needs to be normative, given that one needs to understand that draft to implement the normative bits about modifying anything protected by the signature. OTOH, does this need to reference 4474bis, or would 4474 suffice? -3.1.2: "The mechanism described in Security Considerations section MUST be used by endpoint to detect malicious B2BUA’s that MAY attempt to terminate the DTLS-SRTP session." I'm not sure it makes sense for this draft to put normative requirements on endpoints. Do you mean to say they "can" use the mechanism? Also, that MAY is a statement of fact, not a normative requirement. I'm confused by language about "inspect[ing] the RTP headers and RTCP packets" here and in the subsections. What do you mean about inspecting rtcp packets? Is this an attempt to dance around content inspection? Won't a good portion of the "rtcp packets" be encrypted? - 3.1.2.2: Is the point of this to say b2buas that modify things are out of scope? Not allowed? The paragraph takes the form of "To do A, you must do B, and B is not allowed". It might be easier to say that "You can't do A, because of the issue with B." Can you be more precise about what "break end-to-end security" means? e.g. the receiver would consider the packets invalid? Also, this paragraph might could use another mention of 4474/4474bis. - 4: "Since DTLS operates on the 5-tuple" What does that mean? It sounds something like "encrypts" or "authenticates" the 5, tuple--but I don't think that's what you mean. "unique transport addresses" Do you mean the b2bua must replace each answerers's address with a distinct address? Also do you mean distinct address, or distinct combination of address and port? -5: "This document does not introduce any specific security considerations beyond those detailed in [RFC5763]." It seems like the previous sentence qualified as a security consideration beyond those in 5763. Editorial and nits ================== - Section 1.1: "DTLS-SRTP is defined for point- to-point media sessions" I suggest "currently defined". That's starting to change with PERC. - 3.3, 3rd paragraph from end: s/"B2BUA cannot decrypt..."/"The B2BUA cannot decrypt..." - 3.3, 2nd to last paragraph: "the B2BUA MUST ensure that it does not modify..." I suggest "the B2BUA MUST NOT modify..." - 5:"A malicious B2BUA MAY try to break into the DTLS connection" That shouldn't be a 2119 MAY; it's a statement of fact. |
2015-09-23 |
07 | Ben Campbell | IESG state changed to AD Evaluation from Publication Requested |
2015-09-21 |
07 | Amy Vezza | Notification list changed to draft-ietf-straw-b2bua-dtls-srtp@ietf.org, draft-ietf-straw-b2bua-dtls-srtp.ad@ietf.org, draft-ietf-straw-b2bua-dtls-srtp.shepherd@ietf.org, straw-chairs@ietf.org, christer.holmberg@ericsson.com from "Christer Holmberg" <christer.holmberg@ericsson.com> |
2015-09-21 |
07 | Christer Holmberg | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Intended status: Standards Track Why is this the proper type of RFC? The document contains normative procedures. Is this type of RFC indicated in the title page header? Yes. (2) 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 Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) often act on the media plane, rather than just on the signaling path. This means that B2BUAs often act on the media path leading to separate media legs that the B2BUA correlates and bridges together. The document describes the behavior such B2BUAs can adhere to when acting on the media plane that uses a Secure Real-time Transport (SRTP) security context set up with the Datagram Transport Layer Security (DTLS) protocol. Working Group Summary The WG path of this document was reasonably short and efficient. Several technical comments were made during reviews and all were resolved with consensus. There is consensus in the STRAW WG to publish this document. Document Quality The guidelines and procedures in the document is based on input and experience from the implementer community. Personnel Who is the Document Shepherd? Christer Holmberg (christer.holmberg@ericsson.com -- STRAW WG co-chair) Who is the Responsible Area Director? Ben Campbell <ben@nostrum.com> (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has 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. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) 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 understand and agree with it. (10) 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 publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. idnits 2.13.02 /tmp/draft-ietf-straw-b2bua-dtls-srtp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (September 14, 2015) is 7 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not Applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) 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 plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document makes no request or reference to IANA. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. This document makes no request to IANA. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. This document does not use formal language such as XML code, BNF rules or MIB definitions. |
2015-09-21 |
07 | Christer Holmberg | Responsible AD changed to Ben Campbell |
2015-09-21 |
07 | Christer Holmberg | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2015-09-21 |
07 | Christer Holmberg | IESG state changed to Publication Requested |
2015-09-21 |
07 | Christer Holmberg | IESG process started in state Publication Requested |
2015-09-21 |
07 | Christer Holmberg | Changed document writeup |
2015-09-21 |
07 | Christer Holmberg | Intended Status changed to Proposed Standard from None |
2015-09-21 |
07 | Christer Holmberg | Changed document writeup |
2015-09-21 |
07 | Christer Holmberg | Notification list changed to "Christer Holmberg" <christer.holmberg@ericsson.com> |
2015-09-21 |
07 | Christer Holmberg | Document shepherd changed to Christer Holmberg |
2015-09-14 |
07 | Ram R | New version available: draft-ietf-straw-b2bua-dtls-srtp-07.txt |
2015-08-21 |
06 | Ram R | New version available: draft-ietf-straw-b2bua-dtls-srtp-06.txt |
2015-08-17 |
05 | Ram R | New version available: draft-ietf-straw-b2bua-dtls-srtp-05.txt |
2015-07-22 |
04 | Ram R | New version available: draft-ietf-straw-b2bua-dtls-srtp-04.txt |
2015-06-18 |
03 | Ram R | New version available: draft-ietf-straw-b2bua-dtls-srtp-03.txt |
2015-05-21 |
02 | Tirumaleswar Reddy.K | New version available: draft-ietf-straw-b2bua-dtls-srtp-02.txt |
2015-05-19 |
01 | Tirumaleswar Reddy.K | New version available: draft-ietf-straw-b2bua-dtls-srtp-01.txt |
2015-03-23 |
00 | Ram R | New version available: draft-ietf-straw-b2bua-dtls-srtp-00.txt |