[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] New version of draft-ietf-sip-dtls-srtp-framework
Eric,
Thanks. The new draft takes care of my comments.
John
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of Eric Rescorla
> Sent: 26 August 2008 23:06
> To: sip at ietf.org
> Subject: [Sip] New version of draft-ietf-sip-dtls-srtp-framework
>
> I just submitted a new version of this document intended to address
> the WGLC comments. Attached below are the dispositions of the
> comments I received. Please let me know if I've screwed anything
> up.
>
> -Ekr
>
> John Elwell:
> > This is in good shape - just a bunch of minor comments.
> >
> > 1. "The Real-time Transport Protocol (RTP) [RFC3550] is used
> > to transmit real time media on top of UDP and TCP [RFC4571].
> > Datagram TLS [RFC4347] was introduced to allow TLS
> functionality to
> > be applied to datagram transport protocols, such as UDP and DCCP.
> > This draft provides guidelines on how to establish SRTP [RFC3711]
> > security using an extension to DTLS (see
> [I-D.ietf-avt-dtls-srtp])."
> > This first says that RTP can be used on top of UDP and TCP, but then
> > says that this draft addresses the use of DTLS for
> establishing SRTP.
> > DTLS is applicable only when SRTP is carried over UDP, not TCP. This
> > should be made clear, e.g.,
> > "...guidelines on how to establish SRTP [RFC3711] security
> over UDP..."
>
> Done.
>
>
> > 2. "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."
> > Also there are other places in the draft that mention
> S/MIME, including
> > section 8.3. In the SIP session at IETF72 there was discussion about
> > deprecating S/MIME in SIP. If this is the intent of the WG,
> is it wise
> > to mention the technique in new RFCs?
>
> I think I'd prefer to leave this in here. S/MIME hasn't been
> deprecated
> yet, and it's add to not mention something that after all is in
> RFC 3261 and would get the job done.
>
>
> > 3. "The SIP message
> > containing the offer SHOULD be sent to the offerer's sip
> proxy over
> > an integrity protected channel which SHOULD add an
> identity header
> > according to the procedures outlined in [RFC4474]. "
> > It is the proxy, not the channel, that should add the
> Identity header
> > field. Also some other nits. Change to:
> > "The endpoint SHOULD send the SIP message
> > containing the offer to the offerer's sip proxy over
> > an integrity protected channel. The proxy SHOULD add an Identity
> > header field
> > according to the procedures outlined in [RFC4474]."
>
> Done.
>
>
> > 4. "The far endpoint (answerer) may now establish a mutually
> > authenticated DTLS association to the offerer."
> > This assumes that the far endpoint will play the active
> role. However,
> > that is not necessarily so, and will depend what is
> negotiated in SDP.
>
> Fixed.
>
>
> > 5. "DTLS-SRTP does not provide anonymous calling."
> > Should this say:
> > "DTLS-SRTP does not prevent anonymous calling."?
>
> No, but I agree it's unclear. I rewrote as
>
> The use of DTLS-SRTP does not provide anonymous calling,
> however it also does not prevent it.
>
>
>
> > 6. "Additionally, it MUST be ensured that the Privacy
> header [RFC3325]
> > is
> > used in conjunction with the SIP identity mechanism to
> ensure that
> > the identity of the user is not asserted when enabling anonymous
> > calls."
> > In fact 3325 does not define the Privacy header field - it
> only defines
> > the additional value 'id'. Suggest we say:
> > "Additionally, it MUST be ensured that the Privacy header field with
> > value 'id' [RFC3325]...."
> > I don't know whether we also need a reference to RFC 3323,
> in which case
> > it would become:
> > "Additionally, it MUST be ensured that the Privacy header field
> > [RFC3323] with value 'id' [RFC3325]....".
>
> Fixed.
>
>
> > 7. Should section 6.1 on anonymous calls have an
> informative reference
> > to the ua-privacy draft?
>
> Added.
>
>
> > 8. "Each answerer will create a DTLS association with
> > the offerer."
> > It is not necessarily the case that the answerer will create the
> > association - it could also be the offerer.
>
> s/create/form/
>
>
> > 9. "Once the answer is received, the active endpoint
> > will either reuse the existing association or establish
> a new one,
> > tearing down the existing association as soon as the offer/answer
> > exchange is completed."
> > If the answerer is the active endpoint, how can it
> determine that the
> > offer/answer exchange is completed, i.e., how does it know
> the offerer
> > has received the answer?
>
> Yeeah, that is weird. I think I fixed that.
>
>
> > 10. "Note
> > that this may mean adjusting the endpoint IP addresses if the
> > selected candidate pair shifts, just as if the DTLS
> packets were an
> > ordinary media stream."
> > What is the impact on the in-progress or completed DTLS handshake if
> > there is a shift of IP address?
>
> None. DTLS does not care about IP addresses as long as it gets
> the data it needs.
>
>
> > 11. "Implementations of this specification SHOULD support DTLS-SRTP
> > [I-D.ietf-avt-dtls-srtp]."
> > I thought the whole draft was about DTLS-SRTP. Therefore why is this
> > only SHOULD strength? Under what circumstances are
> exceptions allowed?
> > What are the alternatives to be used in these exceptional
> circumstances?
>
> It should say MUST. It does now.
>
>
> > 12. "Also note
> > that there is a fingerprint attribute on the 'c' line
> of the SDP."
> > An attribute is a separate line, not part of a c-line.
>
> Fixed.
>
>
> > 13. "This is computed from Bob's self-signed certificate."
> > That is true for the answer, but for the offer it is from Alice's
> > certificate.
>
> Doh!
>
>
> > 14. "a=tcap:1 UDP/TLS/RTP/AVP RTP/AVP"
> > Shouldn't this be:
> > "a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP"
>
> Done.
>
>
> > 15. "Message 3 shows Bob
> > sending a DTLS ClientHello directly to Alice for each
> 'm' line in
> > the SDP. In this case two DTLS ClientHello messages
> are sent to
> > Alice. Bob sends a DTLS ClientHello to
> 192.168.1.103:6056 for RTP
> > and another to port 6057 for RTCP."
> > The figure does not show two ClientHello messages, but it should do.
> > This would then make the first sentence above wrong - it
> would be two
> > per 'm'line, not one per 'm' line. It is only one per 'm' line if
> > RTP/RTCP mux is used.
>
> I fixed this by rewriting the text, not the figure.
>
>
> > 16. "Note that in this case, Bob signals the actual
> transport protocol
> > configuration of SRTP over DTLS in the acfg parameter."
> > This appears under message 9 (RTP/RTCP), but really it should occur
> > under message 8 (200 OK).
>
> Fixed.
>
>
> > 17. "When phone number URIs (e.g.,
> > 'sip:+17005551008 at chicago.example.com') are used, there is no
> > structural reason to trust that the domain name is
> authoritative
> > for a given phone number, although individual proxies
> and UAs may
> > have private arrangements that allow them to trust
> other domains."
> > This might suggest that the problem exists only when user=phone is
> > absent, whereas it exists also (more particularly so) when
> user=phone is
> > present. It might be better to say:
> > "When phone number URIs (e.g.,
> > 'sip:+17005551008 at chicago.example.com' or
> > 'sip:+17005551008 at chicago.example.com;user=phone') are used...."
>
> Done.
>
>
> > NITS:
> > - Change "media plan" to "media plane".
> > - "in Enhancements for Authenticated Identity
> > Management in SIP [RFC4474] is used" - delete "in".
> > - "SIP proxies downstream of the identity service" change to "SIP
> > proxies downstream of the authentication service"
> > - "Since the identity header is a
> > digital signature across several SIP headers, in addition to the
> > bodies of the SIP message, "
> > This contains several instances of wrong terminology.
> "identity header"
> > should be "Identity header field. "SIP headers" should be
> "SIP header
> > fields", and "bodies" should be "body". A SIP message has a single
> > header (comprising header fields) and a single body
> (perhaps containing
> > multiple body parts). Similar corrections are needed throughout the
> > document.
>
> I think I got all these.
>
>
> > - "upon receiving the other side's then"
> > I think this should say:
> > "upon receiving the other side's SDP then"
>
> Done.
>
> > - "and key negotiation succeeds otherwise RTP is used"
> > Change to:
> > "and key negotiation succeeds, otherwise RTP is used"
>
> Done.
>
> > - "RTP is the
> > default and will be understood by endpoints that do not
> understand
> > SRTP or this key exchange mechanism but SRTP is preferred."
> > Change to:
> > "This allows an offerer to express a preference for SRTP,
> but RTP is the
> > default and will be understood by endpoints that do not
> understand
> > SRTP or this key exchange mechanism.
>
> Done.
>
> "
> > - "Answerers SHOULD use this UPDATE mechanisms."
> > Change "mechanisms" to "mechanism".
> > - "the assurances of DTLS-SRTP provides "
> > Change to:
> > "the assurances that DTLS-SRTP provides"
> ^^^^
>
> Done.
>
>
> John
>
>
>
>
>
> Hannes Tschofenig:
> > A few random comments:
>
>
> > The fingerprint alone protects against active attacks on
> the media
> > but not active attacks on the signalling. In order to
> prevent active
> > attacks on the signalling, in Enhancements for
> Authenticated Identity
> > Management in SIP [RFC4474] is used.
> >
> > I believe we should indicate that SIP Identity >>may<< be used.
>
> Done.
>
>
> > When Bob receives the offer,
> > Bob establishes a mutually authenticated DTLS connection
> with Alice.
> >
> > It is not really mutually authenticated at this point in time.
> > Something like
> > "
> > When Bob receives the offer,
> > Bob initiates a DTLS exchange with Alice.
> > "
> >
> > At this point Bob can begin sending media to Alice.
> Once Bob accepts
> > Alice's offer and sends an SDP answer to Alice, Alice can begin
> > sending confidential media to Bob.
>
> I rewrote this a little differently.
>
>
> >
> > We would have to assume symmetric RTP (which is only recommended by
> > draft-ietf-avt-dtls-srtp) here to allow Alice to send media
> immediately
> > after the DTLS handshake. Otherwise we may need another
> DTLS handshake
> > before Alice can send media to Bob.
>
> I think the new text covers this.
>
>
> > I was actually wondering why not to mandate symmetric RTP
> given that the
> > number of exchanges are much lower.
>
> the consensus in AVT was not to do so.
>
> > Alice and Bob will verify the
> > fingerprints from the certificates received over the
> DTLS handshakes
> > match with the fingerprints received in the SDP of the
> SIP signaling.
> > This provides the security property that Alice knows
> that the media
> > traffic is going to Bob and vice-versa without
> necessarily requiring
> > global PKI certificates for Alice and Bob.
> >
> >
> > o When RFC 4474 Identity is used, this solution works
> even when the
> > SIP proxies downstream of the identity service are
> not trusted.
> >
> > We could provide a pointer to the security considerations section,
> > namely Section 8.6.
>
> I provided a pointer.
>
>
> > A pointer to RFC 4916 ("Connected Identity"), even though I do not
> > consider it as too important based on the scenarios it
> addresses, would
> > not hurt here.
> > Maybe something like would help:
> > "Retargeting of a dialog-forming request (changing the value of the
> > Request-URI), the UA that receives
> > it (the User Agent Server, UAS) can have a different
> identity from
> > that in the To header field. When RFC 4916 is used then it is
> > possible to supply its identity to the peer UA by means of
> a request in
> > the
> > reverse direction, and for that identity to be signed by an
> > Authentication Service.
> > "
>
> Added.
>
>
> > There is no need to reveal keys in the SIP signaling
> or in the SDP
> > message exchange. In order for SDES and MIKEY to provide this
> > security property, they require distribution of
> certificates to
> > the endpoints that are signed by well known certificate
> > authorities.
> >
> >
> > I believe we should delete the last sentence since we
> provide a detailed
> > discussion of SDES and MIKEY in the media security requirements
> > document.
> >
> Removed.
>
> > Section 5
> >
> > The far endpoint (answerer) may now establish a mutually
> > authenticated DTLS association to the offerer.
> >
> >
> > The same comment from above applies since at this stage
> there two end
> > points aren't mutually authenticated yet.
> >
> >
> > o If the fingerprint does not match the hashed
> certificate then the
> > endpoint MUST tear down the media session immediately.
> >
> > Tentatively establishing a session and tearing it down if the
> > fingerprint doesn't match is one possible strategy.
> Alternatively, the
> > offerer could wait for an answer with the fingerprint and
> subsequently
> > execute the DTLS handshake and cancel the handshake and the session
> > establishment immediately if the cert used in the handshake does not
> > match the fingerprint.
>
> I added some material.
>
>
> > This would obviously delay the establishment of the secure channel.
> > Particularly for early media this would mean that media is
> unprotected.
> > Early media will, however, be tough anyway.
> >
> > I don't have a strong opinion on the two approaches but I believe we
> > should mention the DoS potential in the security
> consideration section.
>
> I don't see that there is any signifciant DoS potential. Can you
> provide some text?
>
>
>
>
> > 6.5. Session Modification
> >
> > Once an answer is provided to the offerer, either endpoint MAY
> > request a session modification which MAY include an
> updated offer.
> > This session modification can be carried in either an INVITE or
> > UPDATE request. Once the answer is received, the active endpoint
> > will either reuse the existing association or establish
> a new one,
> > tearing down the existing association as soon as the offer/answer
> > exchange is completed.
> >
> >
> > I think we need to differentiate the case where the SDP changes only
> > slightly, for example, a change in codec vs. the case where, for
> > example, an IP address changes.
> > Hence, in some cases creating a new association might not even be
> > possible.
>
> I added some text.
>
>
> > Section 7:
> >
> > The SIP signaling from Alice to her proxy is transported
> over TLS to
> > ensure an integrity protected channel between Alice and
> her identity
> > service. Note that all other signaling is transported
> over TCP in
> > this example although it could be done over any
> supported transport.
> >
> > I guess we should also say that the communication between the SIP
> > proxies is protected someone, specifically when SIP
> Identity (or other
> > security mechanisms) is not available.
>
> I added some text.
>
>
> > This shows the initial INVITE from Alice to Bob
> carried over the
> > TLS transport protocol to ensure an integrity
> protected channel
> > between Alice and her proxy which acts as Alice's identity
> > service. Note that Alice has requested to be either
> the active or
> > passive endpoint by specifying a=setup:actpass. Bob
> chooses to
> > act as the DTLS server and will initiate the session.
> Also note
> > that there is a fingerprint attribute on the 'c' line
> of the SDP.
> > This is computed from Bob's self-signed certificate.
> >
> > Shouldn't this be Alice's self-signed cert, as shown in the
> subsequent
> > exchange.
>
> Fixed.
>
>
> > At this point, Bob can begin sending early media (RTP
> and RTCP) to
> > Alice. Note that Alice can't yet trust the media since the
> > fingerprint has not yet been received. This lack of trusted,
> > secure media is indicated to Alice.
> >
> > At the last sentence we should indicate that this
> indication is part of
> > the user interface rather than something that is meant to
> be part of the
> > protocol exchange.
>
> Fixed.
>
> > Section 8: Security Considerations
> >
> >
> > Other mechanisms, such as the S/MIME mechanism described
> > in RFC 3261, or the mechanisms described in
> > [I-D.wing-sip-identity-media] or [I-D.fischer-sip-e2e-sec-media],
> > could also serve this purpose.
> >
> >
> > I believe we should just mention S/MIME and SIP CERT rather than
> > individual drafts that may not go anywhere.
>
> I've removed this, but I have no strong position so I'll put
> it back in
> if people object.
>
>
> > Section 8.2:
> >
> >
> > This sentence is a bit tough to read:
> >
> > If SIP Identity is not used, but the signaling is
> protected by SIPS,
> > the security guarantees are weaker, but some security is still
> > provided as long as all proxies are trusted, this
> provides integrity
> > for the fingerprint.
> >
> >
> > Suggest to break it into 3 sentences:
> >
> > If SIP Identity is not used, but the signaling is
> protected by SIPS,
> > the security guarantees are weaker. Some security is still
> > provided as long as all proxies are trusted. This
> provides integrity
> > for the fingerprint in a chain-of-trust security model.
>
> Done.
>
>
> > It does not provide a strong assertion of who
> > Alice is communicating with. However, as much as the
> target domain
> > can be trusted to correctly populate the From header field value,
> > Alice can use that. The security issue with this
> approach is that if
> > one of the Proxies wished to mount a man-in-the-middle attack, it
> > could convince Alice that she was talking to Bob when really the
> > media was flowing through a man in the middle media
> relay. However,
> > this attack could not convince Bob that he was taking to Alice.
> >
> >
> > I believe that this last paragraph does not provide a lot
> of value given
> > that SIPS fits into the chain of trust security model and hence, by
> > definition, you have to trust the proxies. If the proxies
> are, for some
> > reason, not trustworthy anymore than there is a problem.
>
> I trimmed this down quite a bit.
>
>
> > 8.3. S/MIME
> >
> >
> > I would delete the last sentence from that section, namely
> > "
> > However, so far there have been no deployments of S/MIME
> > for SIP.
> > "
> >
> > Reason: The problem is not really S/MIME as such. The
> problem is how to
> > distribute the certificates. This problem has, however,
> been tackeled
> > with SIP CERT and hence the situation may look different in
> a few years.
> > Additionally, one could argue of lack of deployment of
> other security
> > mechanisms as well.
>
> Removed.
>
> > 8.5. Short Authentication String
> >
> > DTLS does not natively support
> > this mode, however it would be straightforward to add
> one as a TLS
> > extension [RFC3546].
> >
> > I would delete the term "straightforward" and say something like
> > "
> > DTLS does not natively support
> > this mode. Based on the level of deployment interest a TLS
> > extension [RFC3546] could provide support for it.
> > "
> >
> > Reason: There has not been a lot of interest in this
> mechanism lately.
> > Hence, I am not sure whether there is actually a lot
> interest from the
> > community.
>
> Done.
>
>
> > Additionally, it might be useful to indicate that this
> mechanism only
> > helps when you actually know the person's voice. This fits to some
> > communication patters. When you know your communication
> partners already
> > out-of-band then things are a lot easier anyway.
> > For those cases where this is not true things get more
> complicated. For
> > example, how do I know that I talk to a person at my bank, insurance
> > company, car dealer, travel agency, help desk, etc.? One
> may not know
> > the voice of these folks.
>
> Added some material.
>
>
> > Appendix A:
> >
> > A.4. Clipping (R-AVOID-CLIPPING)
> >
> > Because the key establishment occurs in the media plane,
> media need
> > not be clipped before the receipt of the SDP answer.
> >
> >
> > I believe we should indicate that in this case the early
> media is not
> > secured.
>
> That's not 100% accurate. I've added clarifying text.
>
>
> > A.7. (R-SIG-MEDIA, R-ACT-ACT)
> >
> >
> > It might be good to indicate that the interaction between
> the UA and the
> > authentication service needs to be secured as well and that the
> > authentication service is responsible for executing proper
> > authentication of the user.
>
> Done.
>
>
> > A.8. Binding to Identifiers (R-ID-BINDING)
> >
> > We should weaken the language a bit to indicate that other
> mechanisms,
> > such as SIP CERT and S/MIME may also be used and not only
> SIP Identity.
>
> Done.
>
>
> > A.11. RTP Validity Check (R-RTP-VALID)
> >
> > We should also mention STUN packets by referencing Section 5.1.2 of
> > http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-03
>
> Done.
>
>
> > A.15. Denial of Service Vulnerability (R-DOS)
> >
> > DTLS offers some degree of DoS protection particuarly as
> a built-in
> > feature.
> >
> >
> >
> > A.16 is already covered by A.7. I would delete it.
>
>
> Done.
>
>
> > A.18: Maybe we should add one more sentence: "RFC 4474 is able to
> > prevent an active attacker on the signalling path to
> downgrade the call
> > from SRTP to RTP."
>
> Done.
>
>
> > A.22. Interworking with Intermediaries (R-TRANSCODER)
> >
> > "
> > A description of the interworking with Session Border
> Controllers is
> > described in this document.
> > "
> >
> > The interworking with SBCs is covered in
> >
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-pa
> th-middleb
> > oxes-01.txt
> >
> > However, as the text of interworking is written in
> >
> http://www.ietf.org/internet-drafts/draft-ietf-sip-media-secur
> ity-requir
> > ements-07.txt
> > the transcoder needs to have access to the keying material
> and therefore
> > the description from A.21 on media recording (and key disclosure) is
> > applicable here as well.
>
>
> I added a short amount of text.
>
>
> > A.23. PSTN Gateway Termination (R-PSTN)
> >
> > The DTLS-SRTP framework allows the media security to
> terminate at a
> > PSTN gateway. This does not provide end-to-end security, but is
> > consistent with the security goals of this framework because the
> > gateway is authorized to speak for the PSTN namespace.
> >
> >
> > There are several scenarios that would have to be discussed in this
> > context; they are described in Section 3 of
> > draft-schwartz-sip-e164-ownership-01.txt, namely
> > * IP-IP Case (not relevant to Section A.23 although E.164
> numbers are
> > used).
> > * IP-PSTN-IP Case
> > * PSTN-to-IP Case
> > * IP-to-PSTN Case
> >
> > The problems are slightly different for each of these
> cases. However, as
> > most folks would probably agree the security of all these cases is
> > rather weak (or at least unpredictable).
> >
> > I wonder how to best treat this subject but it may not hurt
> to describe
> > the issues in more detail in the appendix. Text is already
> available --
> > hence it would be more of a copy-and-paste operation.
>
> I think this is actually contentious enough that I'd rather not
> get into it, since this is just about media-security-requirements
> compliance.
>
>
> > There are two requirements that have not been discussed:
> R-ALLOW-RTP and
> > R-HERFP.
> >
> > "R-ALLOW-RTP: DTLS-SRTP allows RTP media to be received by
> the calling
> > party until SRTP has been negotiated with the answerer,
> after which SRTP
> > is preferred over RTP.
> > "
> >
> > Here is first try:
> > "
> > R-HERFP: The Heterogeneous Error Response Forking Problem
> (HERFP) is not
> > applicable to DTLS-SRTP since the key exchange protocol
> will be executed
> > along the media path and hence error messages are communicated along
> > this path and proxies do not need to progress them.
> "
>
> I added this text.
>
>
>
> Dan Wing:
> > > From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org]
> On Behalf Of Dean
> > Willis
> > > Sent: Wednesday, July 23, 2008 1:26 AM
> > > To: SIP IETF
> > > Cc: Cullen Jennings
> > > Subject: [Sip] WGLC on DTLS Framework
> draft-ietf-sip-dtls-srtp-framework-02
> > >
> > >
> > > I'm happy to announce a Working Group Last Call on the
> > > standards-track DTLS Framework document:
> > >
> > >
> >
> http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-f
> ramework-02.txt
> > >
> > > I'd like to conclude this WGLC by Friday, August 8, 2008.
> > >
> > > Please review the document and send any comments to the list and
> > > author Eric Rescorla.
> >
> > I'm happy to see this finally WGLC'd, too!
> >
> >
> >
> > Overall:
> >
> > The framework document needs to require endpoints send and
> > receive ietf-mmusic-sdp-capability-negotiation. Without support
> > for that draft, many of the media security requirements cannot be
> > met (as mentioned in A.1 of draft-ietf-sip-dtls-srtp-framework-02).
> > ietf-mmusic-sdp-capability-negotiation should be promoted
> > to a normative requirement, and should be required (MUST) for
> > endpoints to support in order to adhere to the DTLS-SRTP
> framework.
> > Otherwise, we are hosed for forking and hosed for retargeting.
>
> Agreed. Added.
>
>
>
> > Section 1, Introduction:
> >
> > However, even hop-by-hop security such as provided by
> SIPS provides
> > some protection against modification by attackers who
> are not on the
> > signalling path.
> >
> > With or without SIPS, if the attacker is off the signalling
> path, the
> > attacker has little hope of doing much damage -- they need to
> > guess a lot of SDP values and guess a bunch of SIP values (call-id)
> > in order to be successful.
> >
> > So, I would replace the last phrase with:
> >
> > "... who are not in control of on-path signaling elements."
> >
> > resulting in:
> >
> > 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 signaling elements."
>
> Done.
>
>
> > Section 5, Exchanging Certificates:
> >
> > (the text exceeds the section title when it goes beyond just what
> > happens with certificate exchange; perhaps consider re-titling).
> >
> > My slightly more substantive comment is:
> >
> > The answerer SHOULD use the setup attribute value of
> > setup:active and will send the client_hello in the media path."
> > ^^^^
> > MUST
>
> Refined to match your comments and Peter's.
>
>
> > Section 6.6, "ICE Interaction":
> >
> > ...
> > If ICE is not being used, then there is potential for a bad
> > interaction with SBCs via "latching", as described in
> > [I-D.ietf-mmusic-media-path-middleboxes]. In order to avoid this
> > issue, if ICE is not being used and the DTLS handshake has not
> > completed, upon receiving the other side's then the
> passive side MUST
> > ^
> > SDP
> >
> > do a single unauthenticated STUN [I-D.ietf-behave-rfc3489bis]
> > connectivity check in order to open up the appropriate pinhole.
> >
> >
> > Requirements to do something when ICE is *not* being used
> should not be in a
> > section titled "ICE Interaction". I would move this
> paragraph describing how
> > to handle SBC 'latching' to its own section perhaps titled
> "SBC Interaction".
>
> Done.
>
>
> > Section 8.6,
> >
> > o When phone number URIs (e.g.,
> > 'sip:+17005551008 at chicago.example.com') are used,
> >
> > I believe the current consensus is that a phone number would include
> > ;user=phone, so the example should be
> > sip:+17005551008 at chicago.example.com;user=phone
>
> Done
>
>
> > Section 8.6, "Limits of Identity Assertions"
> >
> > (This section is well written.)
> >
> >
> > Implementors should therefore take care not to indicate
> > misleading peer identity information in the user
> interface. e.g. If
> > ^^^^^^
> > formatting
> error around here
> > the peer's identity is
> sip:+17005551008 at chicago.example.com, it is
> > not sufficient to display that the identity of the peer as
> > +17005551008, unless there is some policy that states
> that the domain
> > "chicago.example.com" is trusted to assert E.164 numbers.
> >
> > chicago.example.com only needs to be trusted to assert
> numbers you trust
> > it to assert -- not a blanked "to assert E.164 numbers".
> For example,
> > I might trust, and expect, Verizon to claim E.164s that it owns, but
> > I do not trust, nor expect, Verizon to claim an E.164 with a +353
> > country code.
> >
> > I would revise the above to end with something like:
> >
> > ... unless there is some policy that states that the domain
> > "chicago.example.com" is trusted to assert the E.164 number
> > is it asserting.
> > ^^^^^^^^^^^^^^^
>
> Done.
>
>
> > later,
> >
> > Otherwise, the recipient cannot rely on the RFC 4474 Identity
> > assertion and the UA MUST not indicate to the user that
> a secure call
> > ^^^^^^^^
> > MUST NOT
> > has been established to the claimed identity.
> Implementations which
> > are configured to only establish secure calls SHOULD
> terminate the
> > call in this case.
>
> Done.
>
>
> > Section A.3:
> >
> >
> > add a reference to draft-ietf-avt-dtls-srtp-03.txt
> > which describes how session resumption is supposed to be
> > implemented.
>
> Done.
>
> >
> > Section A.12., "3rd Party Certificates (R-CERTS, R-EXISTING)"
> >
> > Third party certificates are not required. However, if
> the parties
> > share an authentication infrastructure that is
> compatible with TLS
> > (3rd party certificates or shared keys) it can be used.
> >
> >
> > RFC4474 is part of the framework for securing DTLS-SRTP, and
> > as you know there is a lot of consternation around this point.
> > Citing section 13.4 of RFC4474 would be helpful, because section
> > A.12 of sip-dtls-srtp-framework relies on the following small
> > sentence in Section 13.4 of RFC4474:
> >
> > It
> > is strongly RECOMMENDED that self-signed domain
> certificates should
> > not be trusted by verifiers, unless some previous key
> exchange has
> >
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > justified such trust.
> > ^^^^^^^^^^^^^^^^^^^^
>
> I added a reference.
>
>
> > Section A.15, Denial of Service Vulnerability (R-DOS)
> >
> > Please add a reference to Section 4.2.1 of RFC4347.
>
> Done.
>
> >
> > Section A.18., "Downgrading Protection (R-DOWNGRADE)"
> >
> > DTLS provides protection against downgrading attacks since the
> > selection of the offered ciphersuites is confirmed in a
> later stage
> > of the handshake. This protection is efficient unless
> an adversary
> > is able to break a ciphersuite in real-time.
> >
> > This should also mention integrity protection of signaling is
> > necessary in order to prevent downgrade to RTP (because I believe
> > we need to require sdp-capability-negotiation for all of this to
> > work correctly.)
>
> Agreed. added some text per this and Hannes's comments.
>
>
>
>
> > Peter Schneider:
> >
> >
> > 1) The draft currently states in section 5:
> >
> > " The endpoint MUST use the setup attribute defined in
> [RFC4145].
> > The endpoint which is the offerer MUST use the setup attribute
> > value of setup:actpass and be prepared to receive a
> client_hello
> > before it receives the answer. The answerer SHOULD
> use the setup
> > attribute value of setup:active and will send the
> client_hello in
> > the media path."
> >
> > My proposal is to replace the last sentence by "The
> answerer MUST use
> > the setup
> > attribute value of setup:active or the setup attribute value of
> > setup:passive."
>
> I set this to MUST use both but with active as recommended.
>
> The answerer MUST use either a setup attribute value of
> setup:active or setup:passive. Note that if the answerer uses
> setup:passive, then the DTLS handshake will not begin until
> the answerer is received, which adds additional
> latency. setup:active allows the answer and the DTLS handshake
> to occur in parallel. Thus, setup:active is RECOMMENDED. The
> active party MUST send the ClientHello in the media path.
>
> I think this is the best compromise. There's really no advantage
> to being passive.
>
>
> > With this, if the receiver takes up the active role, as
> recommended in
> > the original text, he can start the handshake and if the
> handshake has
> > been carried out successfully before the SDP answer, he can send
> > encrypted early media (before the SDP answer). Obviously,
> with the usage
> > of self signed certificates, the offerer can authenticate
> the origin of
> > the early media only retrospectively, after he has received the SDP
> > answer, which somewhat reduces the value of encrypting the
> early media.
> > Early media as well as a handshake at that point in time
> will however
> > not work in an environment, where middleboxes are present
> that will not
> > let traffic pass in the media plane before the answer has been sent.
> >
> > So if the receiver assumes such an environment, he may
> decide to take up
> > the passive role. By this, the offerer will start the
> handshake as soon
> > as he receives an answer, which would typically be close to
> the first
> > point in time at which the handshake messages will be able
> to pass the
> > middleboxes.
> >
> > I feel it's quite reasonable to do the handshake after
> offer and answer
> > have been exchanged, because the offerer can check the
> fingerprint of
> > the certificate received in the handshake immediately; and
> he will not
> > accept encrypted media that may be sent by an attacker. So
> he is less
> > vulnerable to DoS. This does not allow encrypted early media to be
> > received, but is this so essential? In fact, accepting only
> encrypted
> > early media could be harmful, as it would prevent a caller
> to receive
> > e.g. an announcement that is sent by some server in the network that
> > only sends unsensitive announcements and therefore does not support
> > encryption at all.
>
> I think this is covered in the security considerations section.
>
> I don't really understand what DoS issue you're concerned about.
>
>
>
> > 2) With respect to unmanaged (e.g. residential) stateful
> firewalls the
> > draft currently states in section 6.6 that if ICE is not
> used and the
> > handshake could not be completed (until offer and answer have been
> > exchanged)
> >
> > "the passive side MUST
> > do a single unauthenticated STUN [I-D.ietf-behave-rfc3489bis]
> > connectivity check in order to open up the appropriate
> pinhole. All
> > implementations MUST be prepared to answer this request during the
> > handshake period even if they do not otherwise do ICE."
> >
> > And later, in the message flow on page 13 and the respective
> > explanations it becomes obvious that the idea is that the
> sender of this
> > STUN connectivity check in fact waits for an answer before
> he proceeds
>
> That's not intended at all. They're done in parallel.
>
>
> > (although implementations must only *be prepared* to answer a
> > connectivity request - I wonder whether "be prepared"
> should rather be
> > removed from this sentence). However, if there are
> middleboxes on the
> > path that block the STUN connectivity check, an answer will
> never come,
> > although the purpose of the connectivity check - to
> establish a session
> > in the residential firewall and open it up for incoming
> traffic - may
> > already have been achieved.
> >
> > So instead of making the sending of the STUN connectivity check
> > mandatory in this situation, I propose rather to recommend that the
> > passive UA in the connection setup should try to make sure that a
> > firewall protecting the UA does not block the client hello
> starting the
> > handshake. This could be done by STUN or other means. This
> is exactly
> > what is recommended also in
> draft-ietf-mmusic-media-path-middleboxes-01,
> > section 7, REC #1.
>
> I think IETF general policy is to prefer ICE, which is what you
> would do here. This is a stopgap.
>
>
> > 3) More generally, I propose that the draft should mention possible
> > problems with middleboxes, and should advise implementors
> to follow the
> > recommendations in draft-ietf-mmusic-media-path-middleboxes.
>
> I don't want to create a normative reference, but I added a
> section that points at that and states it has recommendations.
>
>
> > 4) Concerning the possible sequence of messages used to establish
> > sessions that use DTLS-SRTP, the draft IMO should give clearer
> > recommendations. This is currently mostly treated in the section
> > "example message flow", which indeed explains two flows
> currently. It is
> > unclear, to which degree this is normative, and what
> variants of such
> > flows would also be considered compliant to the draft.
>
> I went through and tried to add some clarifying text where I thought
> appropriate. That said, since TLS allows inband negotiation and
> there is some inherent reordering due to the use of multiple parallel
> flows, a lot of different variants are legal. Is there some particular
> point you want clarified?
>
>
> > 5) Another topic where information is only given in the
> example flows is
> > the treatment of RTCP. If RTP/RTCP multiplexing on a single
> port is not
> > used, at which time should the handshake for RTCP be done -
> immediately
> > after the handshake for RTP, so that sender reports could
> be sent for
> > early media? Or only after the SDP answer, when both sides
> know which
> > ports are used on both sides? This becomes even more complex, if
> > non-symmetric RTP/RTCP would be applied, which is not excluded in
> > draft-ietf-avt-dtls-srtp-02.
> > I propose to describe these issues in a dedicated section.
>
> I added some text and referenced the AVT draft which talks about
> the performance issues.
>
> -Ekr
>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip