Subject: [Sip] Review of draft-ietf-sip-media-security-requirements-04

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Apr 2008 18:14:09 -0700

$Id: draft-ietf-sip-media-security-requirements-04-rev.txt,v 1.2 2008/04/05 00:53:27 ekr Exp $

This document seems to me to be in good shape.

I have the following comments about this document. None of these are critical
so I won't cry if they don't get made, and I don't want them to hold
the document up if they're controversy.

S 4.1.
   which it is detect-attack, which provides protection against the

"which is"?

   before the SDP answer arrives) might make the requirements to become
   obsolete, but at the time of writing no progress has been

Not sure I know what this means: "to become obsolete" seems ungramattical
here. 

S 4.3.
The entire section on shared key conferencing doesn't lead to any
requirements as far as I can tell. Does it make sense to remove
it from this document?

S 5.1.
   R-DISTINCT:
         The media security key management protocol MUST be capble of
s/capble/capable/

S 5.3.
   R-OTHER-SIGNALING:
         A solution SHOULD be able to negotiate keys for SRTP sessions
         created via different call signaling protocols (e.g., between
         Jabber, SIP, H.323, MGCP).

This is not discussed anywhere in the document. I wonder if it makes
sense to remove it.

Appendix A.
   Based on how the SRTP keys are exchanged, each SRTP key exchange
   mechanism belongs to one general category:

      signaling path:  All the keying is carried in the call signaling

Remove one blank line here.

S A.1.12.
It's a little weird to have the discussion of media path keying 
properties here before you describe the systems.

S A.1.12.2.
The issues you raise about middleboxes and clipping apply equally
to DTLS-SRTP and ZRTP, no?

S A.1.12.3.
Again, I would think to remove this section.

      DTLS-SRTP
         Keying: Yes, because with the assumed cipher suite,
         TLS_RSA_WITH_3DES_EDE_CBC_SHA, each end indicates its SRTP key.

This statement is not correct. With all conventional TLS modes, neither
side completely controls either key.

S A.1.13.1.
The way you're using "public key cryptography" to mean "PKI" is not
the normal terminology. DH is PKC. I would use PKI to indicate
"certs are needed". So, for instance, SDP-DH and ZRTP definitely use
PKC.

         PFS is achieved if the negotiated cipher suite includes an
         exponential or discrete-logarithmic key exchange (e.g., Diffie-
         Hellman (DH_RSA from [RFC4346]) or Elliptic Curve Diffie-
         Hellman [RFC4492]).

I don't know what "exponential or discrete logarithmic key exchange"
means. After all, RSA involves exponentiation. Presumably you mean
"something with ephemeral keys". This currently means discrete log
over integer and elliptic curve fields, but could be RSA in principle.

S A.1.13.3.
It's probably important to indicate that it is desirable to have
the profile be RTP/SAVP when SRTP is used. That's a disadvantage
of media path probing, for instance. I don't think that comes
across clearly here.

S A.3.2.
   This document assumes DTLS will use TLS_RSA_WITH_3DES_EDE_CBC_SHA as
   its cipher suite, which is the mandatory-to-implement cipher suite in
   TLS [RFC4346].

I'm not sure what the relevance of this is. I guess RSA matters, but
since we negotiate a separate protection profile for SRTP, 3DES/SHA
isn't that relevant. Btw, TLS 1.2. will be AES.

Note also that DTLS-SRTP is compatible with RTP before the DTLS
handshake.

-Ekr

_______________________________________________
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: "Dan Wing" <[email-masked]>
Date: Wed, 9 Apr 2008 18:10:05 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rescorla
> Sent: Friday, April 04, 2008 6:14 PM
> To: [email-masked]; 
> [email-masked]
> Subject: [Sip] Review of draft-ietf-sip-media-security-requirements-04
> 

Fixed.

> Not sure I know what this means: "to become obsolete" seems 
> ungramattical here. 

Changed to:

  Preventing the arrival of early media (i.e., media that 
  arrives at the SDP offerer before the SDP answer arrives) 
  might obsolete the R-AVOID-CLIPPING requirement, but at the 
  time of writing such early media exists in many normal call 
  scenarios.

> requirements as far as I can tell. Does it make sense to remove

Right.  It seems useful to leave it in, as mentioned at the beginning
of the section:

   The consensus on the RTPSEC mailing list was to concentrate on
   unicast, point-to-point sessions.  Thus, there are no requirements
   related to shared key conferencing.  This section is retained for
   informational purposes.

if others agree it should be removed, I can remove it.

>          The media security key management protocol MUST be capble of

Fixed.

> This is not discussed anywhere in the document. I wonder if it makes

I know that my employer's products interwork between SIP and MGCP (and 
our proprietary SCCP) with SRTP today -- all using Security Descriptions.

I know we have a need to meet this requirement with anything that 
replaces our Security Descriptions implementations.  I expect others
do, too.  

Would adding motivating text (in a new subsection 4.xxx) be useful?  I
had assumed the need was self-evident.

> properties here before you describe the systems.

I moved A.1.12 to a new section A.4.
 
> to DTLS-SRTP and ZRTP, no?

ZRTP allows RTP to flow while the ZRTP exchange is happening, so ZRTP
should incur no clipping.

> Again, I would think to remove this section.

This is the 'centralized keying' section, which is derived from the
conferencing discussion (for which we have no requirements in the
document -- only a non-normative discussion).

I will remove it, unless someone objects.

> This statement is not correct. With all conventional TLS 
> modes, neither side completely controls either key.

Agreed.  It is in the removed section, so it's gone entirely anyway.

> "certs are needed". So, for instance, SDP-DH and ZRTP definitely use

Ok.  Changed from:

   Using public key cryptography for confidentiality and authentication
   can introduce requirements for two types of systems: (1) a system to
   distribute public keys (often in the form of certificates), and (2) a
   system for validating certificates.

to:

   Requiring certificates for confidentiality and authentication 
   can introduce requirements for two types of systems: (1) a system to 
   distribute certificates, and (2) a system for validating certificates. 

> over integer and elliptic curve fields, but could be RSA in principle.

Thanks.  I don't know where that text came from (it isn't my wording
but it was in my original -00).  Changed to:

      DTLS-SRTP
         PFS is provided if the negotiated cipher suite uses ephemeral
         keys (e.g., Diffie-Hellman (DH_RSA from [RFC4346]) or Elliptic
         Curve Diffie-Hellman [RFC4492]).

> of media path probing, for instance. I don't think that comes

There is a disadvantage with RTP/SAVP as the profile, as well, mentioned at
the beginning of that section -- just prior to the list of candidate
techniques.  

This section is titled Best Effort Encryption, and RTP/SAVP is not a candidate
technique to provide best effort encryption -- RTP/SAVP causes a call to fail
to complete if any of the remote forks or targets (during retargeting) rejects
the call because they don't understand that profile.  This is discussed at the
beginning of that section, in order to justify why we need best effort
encryption -- so that we can deploy SRTP without a priori knowledge of the
called party's deployment of RTP/SAVP-capable endpoints at that particular
moment.

> I'm not sure what the relevance of this is.

This is relevant because I could have assumed a null cipher instead, which
would change much of the analysis.  If we use DH_RSA

> I guess RSA matters, but

Thanks, changed to:

   This document assumes DTLS will use TLS_RSA_WITH_AES_128_CBC_SHA as
   its cipher suite, which is the mandatory-to-implement cipher suite in
   TLS [I-D.ietf-tls-rfc4346-bis].

> Note also that DTLS-SRTP is compatible with RTP before the DTLS

Only if the RTP profile is RTP/AVP; if the profile is RTP/SAVP, one expects
only SRTP.  Is there text that needs to change to note that in the
requirements doc?

-d

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 09 Apr 2008 20:05:50 -0700

At Wed, 9 Apr 2008 18:10:05 -0700,

>   time of writing such early media exists in many normal call 

Looks good.

> if others agree it should be removed, I can remove it.

I've got no real problem with leaving it in, I just wanted
to note it.

> had assumed the need was self-evident.

As a matter of form, I think it would be good to have a section
with motivating text.

>    distribute certificates, and (2) a system for validating certificates. 

Looks good.

>          Curve Diffie-Hellman [RFC4492]).

s/DH_RSA/DHE_RSA/. DH_RSA means static keys.

> called party's deployment of RTP/SAVP-capable endpoints at that particular

So, maybe I just misunderstood the situation: I had thought that 
with the new media cap stuff one would offer both RTP/SAVP and
RTP/AVP, so you would get best effort. Am I confused?

> only SRTP.  Is there text that needs to change to note that in the

Not sure. See my comment above about RTP/SAVP.

-Ekr

---

From: Dan York <[email-masked]>
Date: Thu, 10 Apr 2008 22:40:04 -0400

On Apr 9, 2008, at 9:10 PM, Dan Wing wrote:
Dan,

> if others agree it should be removed, I can remove it.

DY> I agree that it is useful to leave the information in there,  
primarily to prevent people reading the document and saying "But what  
about shared key conferencing?".  However, it does seem somewhat  
strange to have it there in the Call Scenarios section when there are  
no requirements for that particular call scenario.

DY> What if you were to move it into an Appendix - perhaps into the  
existing Appendix B where you have already indicated that shared key  
conferencing is out-of-scope (this section would then elaborate on  
the point of why it is difficult), or perhaps into a new Appendix.

My 2 cents,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Apr 2008 14:28:51 -0700

Eric Rescorla wrote:

...
> > Right.  It seems useful to leave it in, as mentioned at the 
> > beginning of the section:
> > 

I moved it into Appendix B, which Dan York suggested.  That accomplishes
the goal of documenting the decision and clearly making the discussion
text non-normative.

> > Would adding motivating text (in a new subsection 4.xxx) be 
> > useful?  I had assumed the need was self-evident.
> 

Ok.  I added a new section to justify R-OTHER-SIGNALING:

   4.8.  Interworking with Other Signaling Protocols

   The discussion in this section relates to the requirement R-OTHER-
   SIGNALING.

   In many environments, some devices are signaled with protocols other
   than SIP which do not share SIP's offer/answer model (e.g., [H.248.1]
   or do not utilize SDP (e.g., H.323).  In other environments, both
   endpoints may be SIP, but may use different key management systems
   (e.g., one uses MIKEY-RSA, the other MIKEY-RSA-R).

   In these environments, it is desirable to have SRTP -- rather than
   RTP -- between the two endpoints.  It is always possible, although
   undesirable, to interwork those disparate signaling systems or
   disparate key management systems by decrypting and re-encrypting each
   SRTP packet in a device in the middle of the network (often the same
   device performing the signaling interworking).  This is undesirable
   due to the cost and increased attack area, as such an SRTP/SRTP
   interworking device is a valuable attack target.

   At the time of this writing, interworking is considered important.
   Interworking without decryption/encryption of the SRTP, while useful,
   is not yet deemed critical because the scale of such SRTP deployments
   is, to date, relatively small.

and a new section to justify R-CERTS (based on comments I received from
another reviewer):

   4.9.  Certificates

   The discussion in this section relates to R-CERTS.

   On the Internet and on some private networks, obtaining certificates
   issued by a certificate authority can be difficult or expensive, and
   requires peers to trust the issuing certificate authority.  For these
   reasons, it is important that authentication mechanisms that utilize
   certificates not rely exclusively on such CA-issued certificates, but
   to also allow self-signed certificates.  By allowing the use of such
   self-signed certificates, an out-of-band mechanism (e.g., manual
   configuration) can be used to trust a peer's certificate.

Here are the other requirements in the document which do not have text to
motivate the requirements.  Which of these -- or perhaps all of them? --
should have additional text written:

   R-RTP-VALID:
         If SRTP key negotiation is performed over the media path (i.e.,
         using the same UDP/TCP ports as media packets), the key
         negotiation packets MUST NOT pass the RTP validity check
         defined in Appendix A.1 of [RFC3550].

   R-NEGOTIATE:
         The media security key management protocol MUST allow a SIP
         User Agent to negotiate media security parameters for each
         individual session.

   R-PFS:
         The media security key management protocol MUST be able to
         support perfect forward secrecy.

   R-COMPUTE:
         The media security key management protocol MUST support
         offering additional SRTP cipher suites without incurring
         significant computational expense.

   R-DOS:
         The media security key management protocol SHOULD NOT introduce
         new denial of service vulnerabilities (e.g., the protocol
         should not request the endpoint to perform CPU-intensive
         operations without the client being able to validate or
         authorize the request).

   R-EXISTING:
         The media security key management protocol SHOULD allow
         endpoints to authenticate using pre-existing cryptographic
         credentials, e.g., certificates or pre-shared keys.

   R-AGILITY:
         The media security key management protocol MUST provide crypto-
         agility, i.e., the ability to adapt to evolving cryptography
         and security requirements (update of cryptographic algorithms
         without substantial disruption to deployed implementations)

   R-DOWNGRADE:
         The media security key management protocol MUST protect cipher
         suite negotiation against downgrading attacks.
 
   R-ALLOW-RTP:  A solution SHOULD be described which 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.

Related to this, the two requirements R-ASSOC and R-FIPS have in-line
justifications (rather than a discussion in a separate section).  This was
done because they are relatively short, but for style reasons (and because
some of the newer motivational text is now quite short) we could move those
justifications out of Section 5 (requirements) and into section 4 (call
scenarios and requirements considerations).  I don't care much either way.

...
> s/DH_RSA/DHE_RSA/. DH_RSA means static keys.

Thanks, fixed.

> > called party's deployment of RTP/SAVP-capable endpoints at 
> > that particular moment.
> 

We do -- but the SDP capability negotiation does not put RTP/SAVP
on the "m=" line (which is where the profile is indicated).  Rather, 
SDP capability negotiation puts the RTP/SAVP profile into an "a=" 
line.

-d