[Sip] Review of draft-ietf-sip-media-security-requirements-03

[Eric Rescorla <ekr at networkresonance.com>]

$Id: draft-ietf-sip-media-security-requirements-03-rev.txt,v 1.1 2008/02/28 17:10:00 ekr Exp $

GENERAL COMMENTS
I'm concerned about the apparent lack of stability of this draft.
When this draft was originally published, it seemed to me to
have two purposes:

- To capture the BOF consensus on the important security
  properties for an RTPSEC protocol.
- To be a survey for the properties of
  the various protocols compared to those requirements.

The first purpose still seems useful to me, but is best served
by having a draft that reflects that consensus published 
ASAP. The second purpose seems to me to have been sort
of overtaken by events and I'm not sure it's still valuable.

With the first purpose firmly in mind, it seems a little problematic
that this draft has changed so much in the past 6-12 months.
In particular:

- The -02 version totally renamed all the requirements
- I'm not convinced that all the requirements 
  introduced in -00 have WG consensus.

Since there are other documents which need to reference these
requirements, this presents a problem for them.

IMO we should try to quickly converge on the requirements we have
consensus on, remove others, and publish this document as a historical
statement. We should also consider whether the appendices with
the survey of the protocols is really that useful in an archival
document.


DETAILED COMMENTS
S 4.2.
   retargeting problem.  While Connected Identity [RFC4916] allows
   positive identification of the called party, the primary difficulty
   still remains that the calling party does not know if a mismatched
   called party is legitimate (i.e., due to authorized retargeting) or
   illegitimate (i.e., due to unauthorized retargeting by an attacker
   above to modify SIP signaling).

This is totally true, but it's not a media security issue. It's
a SIP issue.

S 4.3.
   though it does consume additional cryptographic context on the mixer
   for each participant and has the advantage of non-repudiation of the
   originator of the incoming stream.

This isn't non-repudiation. It's data origin authentication.
When you have a shared group key, anyone who has the key can impersonate
anyone else. Pairwise keys remove this problem, but they don't
stop me from forging data on our pairwise and claiming it's from you
to a third party. That's non-repudiation.

Also, this section needs discussion of the advantages and 
disadvantages of (d).

R-ID-BINDING:
This requirement doesn't really make sense as stated. 
What needs to be bound isn't an identifier, it's the
media security keys. Imagine a scheme in which new
raw DH shares were generated for each connection and
the public share was Identity signed. That's not 
an identifier, but it's secure.

R-RECORDING:
I don't believe that there is WG consensus on this requirement.

R-TRANSCODER:
I don't think this requirement makes sense as stated.
Any SRTP-using system can always allow transcoding by
having one side share the keys with the transcoder.






-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