Subject: [Sip] WGLC comments on draft-ietf-sip-dtls-srtp-framework-02

From: "Elwell, John" <[email-masked]>
Date: Fri, 08 Aug 2008 18:05:05 +0100

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..."
                                                           ^^^^^^^^

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?

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]."

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.

5. "DTLS-SRTP does not provide anonymous calling."
Should this say:
"DTLS-SRTP does not prevent anonymous calling."?
                    ^^^^^^^
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]....".

7. Should section 6.1 on anonymous calls have an informative reference
to the ua-privacy draft?

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.

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?

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?

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?

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.

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.

14. "a=tcap:1 UDP/TLS/RTP/AVP RTP/AVP"
Shouldn't this be:
"a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP"
                      ^
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.

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).

17. "When phone number URIs (e.g.,
      'sip:[email-masked]') 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:[email-masked]' or
'sip:[email-masked];user=phone') are used...."

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.
- "upon receiving the other side's then"
I think this should say:
"upon receiving the other side's SDP then"
                                 ^^^
- "and key negotiation succeeds otherwise RTP is used"
Change to:
"and key negotiation succeeds, otherwise RTP is used"
                             ^
- "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."
- "Answerers SHOULD use this UPDATE mechanisms."
Change "mechanisms" to "mechanism".
- "the assurances of DTLS-SRTP provides "
Change to:
"the assurances that DTLS-SRTP provides"
                ^^^^

John

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 11 Aug 2008 19:12:03 +0300

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.

  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.

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 was actually wondering why not to mandate symmetric RTP given that the
number of exchanges are much lower. 

 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. 
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. 
"

      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. 

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.

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. 

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. 

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. 

      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. 

      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. 

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. 

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. 

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. 

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. 

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. 

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. 

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.

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. 

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. 

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

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. 

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."

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-path-middleb
oxes-01.txt

However, as the text of interworking is written in
http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-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. 

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. 

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.
"
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip