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

From: "Dan Wing" <[email-masked]>
Date: Sat, 8 Mar 2008 20:34:22 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rescorla
> Sent: Thursday, February 28, 2008 9:31 AM
> To: [email-masked]
> Subject: [Sip] Review of draft-ietf-sip-media-security-requirements-03
> 
> $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

That was an editorial change requested by several reviewers, who found the
numbering willy-nilly; related requirements were not together.  Also, one
requirement (R24) was removed by working group consensus, creating a hole in
the numbering.

> - I'm not convinced that all the requirements 
>   introduced in -00 have WG consensus.

That may be, but the mailing list is too quiet for me to judge that very well.

> 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.

This will be adjusted to refer to data origin authentication in -04.  Thanks.

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

Ok.  -04 adds the following text discussing (d), the 'single outbound'
scenario:
 
    The significant advantage of a single outbound session is the
    number of SRTP encryption operations remains constant even as
    the number of participants increases.  However, a
    disadvantage is that data origin authentication is lost,
    allowing any participant to spoof the sender (because all
    participants know the sender's SRTP key).

> 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.

This will be reworded in -04 using Matt's suggested text:

     The media security key management protocol must enable 
     the media security keys to be cryptographically bound to 
     an identity of the endpoint.

> 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.

This states a requirement for a system, not a requirement
directly upon the key management itself.  As Matt pointed out, 
R-RECORDING and R-TRANSCODER require a description, somewhere, 
of how this might be performed.  

For R-RECORDING, as stated in the discussion text, some types 
of businesses have legal requirements to record communications 
between their own employees (stock analysts and stock brokers 
are the best examples), and some businesses have their own 
internal requirements to record conversations with customers 
(the ubiquitous "This Call Is Being Recorded For Quality Purposes"
we all hear when calling a travel agent, bank, etc.).  

Are you saying that the working group doesn't believe those
businesses should encrypt with SRTP (and should rather meet
their requirements by sticking with RTP)?  Because without a
solution to meet that requirement, that is all those businesses
can do.

-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-masked] for questions on current sip
> Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip