Eric Rescorla wrote:
...
> > > 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.
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.
> > > 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.
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.
...
> > 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.
Thanks, fixed.
> > > 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?
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
_______________________________________________
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
