Subject: [Sip] media-security-requirements-01

From: "Dan Wing" <[email-masked]>
Date: Sun, 18 Nov 2007 18:41:26 -0800

I just submitted draft-ietf-sip-media-security-requirements-01.  Changes from
-00 to -01 include:

  * Deleted R24 (which pertained to lawful intercept)
  * Categorized requirements (SIP Forking/Retargeting,
    security characteristics, performance consideration, 
    media considerations).
  * The text of several of the requirements was tightened
    up.
  * Additional justification was provided for several of
    the requirements.

In -01, I am aware of three outstanding issues:

1. Richard Barnes has suggested we remove R12, which is:

      R12:  The media security key management protocol 
            MUST NOT require 3rd parties to sign 
            certificates.

because no-one would be insane enough to design a 
protocol that required 3rd parties in order to
function.

Comments?

2. There has been some confusion regarding R15, and I don't 
know how to best resolve it.  R15 is:

      R15:  The media security key management protocol 
            SHOULD allow endpoints to start with RTP and 
            then upgrade to SRTP.
    
This has been interpreted differently by different people
and by different specifications.  In the document, I 
highlighted the different interpretations:

         Issue: Does this mean
         [I-D.ietf-mmusic-sdp-capability-negotiation] (which 
         overlaps with R1 and R2), allow RTP during early 
         media (and upgrade to SRTP when the SDP answer 
         arrives), or support an "Encrypt this call" 
         button on the phone?

I suggest splitting this requirement apart into those 
three parts:  MUST work with sdp-cap-neg, SHOULD allow
RTP early media with upgrade to SRTP, and SHOULD allow
upgrading from RTP to SRTP mid-call with a re-invite.  
Comments?

* Requirement R25 tries to describe the need for transcoders
to work with SRTP keying; however, I don't know how this would
actually be done except via Security Descriptions (where the
transcoder would just pretend to be the real endpoint, because
the transcoder has easy access to the SRTP key).  The current
text is:

      R25:  The media security key management protocol 
            MUST work when there are intermediate nodes 
            (e.g., transcoders), terminating or processing 
            media, between the end points.

Something like draft-wing-sipping-srtp-key could be helpful
to meet this requirement (so that the endpoint, which knows
it wants transcoding services, provides the transcoder with
the necessary keys).  However, this involves changes to call
flows and I don't know if anyone is yet willing/able to work
on such a call flow.

Comments on this requirement?

-d

_______________________________________________
Sip mailing list  https://www1.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