[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Review of draft-ietf-sip-media-security-requirements-04
At Wed, 9 Apr 2008 18:10:05 -0700,
Dan Wing wrote:
> > 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.
Looks good.
> > 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.
I've got no real problem with leaving it in, I just wanted
to note it.
> > 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.
As a matter of form, I think it would be good to have a section
with motivating text.
> > 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.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.
Looks good.
> > 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/DH_RSA/DHE_RSA/. DH_RSA means static keys.
> > 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.
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?
> > 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?
Not sure. See my comment above about RTP/SAVP.
-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