> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Eric Rescorla
> Sent: Friday, April 04, 2008 6:14 PM
> To: [email protected];
> [EMAIL PROTECTED]
> Subject: [Sip] Review of draft-ietf-sip-media-security-requirements-04
>
> $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"?
Fixed.
>
> 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.
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.
> 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?
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.
> S 5.1.
> R-DISTINCT:
> The media security key management protocol MUST be capble of
> s/capble/capable/
Fixed.
> 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.
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.
> 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.
I moved A.1.12 to a new section A.4.
> S A.1.12.2.
> The issues you raise about middleboxes and clipping apply equally
> to DTLS-SRTP and ZRTP, no?
ZRTP allows RTP to flow while the ZRTP exchange is happening, so ZRTP
should incur no clipping.
> S A.1.12.3.
> 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.
> 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.
Agreed. It is in the removed section, so it's gone entirely anyway.
>
> 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.
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.
> 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.
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]).
> 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.
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.
> 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.
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
> since we negotiate a separate protection profile for SRTP, 3DES/SHA
> isn't that relevant. Btw, TLS 1.2. will be AES.
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
> handshake.
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
>
>
>
> -Ekr
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [EMAIL PROTECTED] for questions on current sip
> Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
