RE: I-D ACTION:draft-wing-media-security-requirements-00.txt

["Fries, Steffen" <steffen.fries@xxxxxxxxxxx>]

Hi Hadriel,

> 1) I don't believe there was a vote on "R3: With forking, 
> only the entity to which the call is finally established, 
> MUST get hold of the media encryption keys" explicitly.  The 
> slide we voted on was "Forking and Retargeting MUST/SHOULD be 
> secured".  That was ambiguous, at least for me in Montreal.
> The way the slide was discussed it sounded like "do we still 
> need to have a forked request secured", whereas what I think 
> you really meant, now that I see this requirement, is "must 
> we prevent all forked parties from seeing the keys, and 
> instead constrain it to only the final chosen one".  A very 
> different question, with a very different answer for me.
I just looked up the meeting minutes EKR provided
(http://www3.ietf.org/proceedings/06jul/minutes/rtpsec.txt) from the
last RTPSEC meeting to see if we stated something wrong. The meeting
minutes have been on the list for comments.
The very first point states:
1. Forking and retargeting
    MUST work with all end-points being SRTP.
    MUST work with mix of SRTP and RTP endpoints.
    Not acceptable for all endpoints to see the keys
    with forking.
    OK to start with RTP and then upgrade to SRTP.

>From that I understand your latter statement.

 
> 2) R6: A solution MUST provide protection against passive 
> attacks.  I think you need to define what a passive attack is 
> in the draft.  It was also an area where I thought the voting 
> was ambiguous.  In the earlier slides they implied a proxy, 
> in the SIPS/TLS hop-path of an sdesc request, would be 
> considered a passive attacker; so sdesc through SIPS through 
> proxies would not be sufficient to be considered a valid 
> rtpsec model.  But I don't think that's what the requirement 
> voting slide implied, and not what some people voted on in 
> Montreal.  At least I didn't.  I was voting that the keys had 
> to be exchanged over a secure transport mechanism, so that a 
> sniffer wouldn't see 'em.  Now I know some people here feel a 
> SIPS proxy and a sniffer are the same thing, but I don't.  :) 
>  But I'd at least like to know whether it is or not in this 
> draft's view.
You are right, we will include a description of whats is meant by a
passive attack.
Regarding the SIPS discussion, I don't think we should mix it in here.
This is a requirements draft in the first place stateing requirements
for media data security and associated key management. Stateing SIPS
here as a requirement would preclude the solution.

Regards
  Steffen
 

> 
> -hadriel
> 
> 
> > -----Original Message-----
> > From: owner-ietf-rtpsec@xxxxxxxxxxxx [mailto:owner-ietf- 
> > rtpsec@xxxxxxxxxxxx] On Behalf Of Dan Wing
> > Sent: Tuesday, October 24, 2006 7:14 PM
> > To: ietf-rtpsec@xxxxxxx
> > Cc: Steffen Fries; Hannes Tschofenig
> > Subject: FW: I-D 
> ACTION:draft-wing-media-security-requirements-00.txt
> > 
> > Now that the I-D deadlines are passed, I wanted to call RTPSEC's 
> > attention to our recent submission.  This I-D is intended 
> to summarize 
> > the requirements from my RTPSEC BoF presentation and 
> discussions on this list.
> > 
> > Please reply-all with comments or suggestions.
> > 
> > -d
> > 
> > 
> > > 	Title		: Media Security Requirements
> > > 	Author(s)	: D. Wing, et al.
> > > 	Filename	: draft-wing-media-security-requirements-00.txt
> > > 	Pages		: 19
> > > 	Date		: 2006-10-18
> > >
> > >
> > >    A number of proposals have been published to address 
> the need of
> > >    securing media traffic.  Different assumptions, 
> requirements, and
> > >    usage environments justify every one of them.  This
> > >    document aims to summarize the discussed media security
> > >    requirements in order progress the work on identifying a
> > >    small subset applicable to a large range of deployment
> > >    environments.
> > >
> > >
> > > A URL for this Internet-Draft is:
> > >
> > http://www.ietf.org/internet-drafts/draft-wing-media-security-
> > requirements-0
> > 0.txt
> 
> 
>