IETF Real Time Protocol Security ()

Dan Wing | 25 Oct 2006 01:13

Picon

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

(Continue reading)

Alan Johnston | 25 Oct 2006 19:02

[Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt]


All,

The ZRTP I-D has been updated.  There are lots of changes in the 
document including:

- Discussion of how ZRTP compares using the criteria in 
draft-wing-rtpsec-keying-eval-01.txt

- Discovery and authentication of ZRTP through the signaling channel and 
the definitions and ABNF of three SDP attributes a=zrtp, a=zrtp-sas, 
a=zrtp-sasvalue.

- New Multistream key agreement mode allowing SRTP keys for multiple 
media streams in a session to be derived from a single  ZRTP DH exchange.

- CRC protection of ZRTP messages against transport errors using a 32 
bit CRC algorithm

- Use of RTP no-op packets instead of comfort noise packets

- Simplified shared secret comparison algorithm

- New Stay secure and Disclosure flags

- More details on caching of retained shared secrets including 
expiration intervals

- Removal of Error message - Reason field added to GoClear

(Continue reading)

Philip Zimmermann | 25 Oct 2006 19:29

Picon

Re: [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt]


In the category of full disclosure, I wanted everyone to be aware of  
an Intellectual Property disclosure I just made to the IETF.  The  
full text can be found at:

     https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=752

While patents are distasteful to me, and I have seen how they have  
been damaging in the crypto world, this is a purely defensive patent  
that I have filed.  My intention is to provide royalty-free licenses  
to anyone implementing ZRTP under most circumstances.  Provided they  
are not suing me or my customers for infringing a patent. 

The exact text is:

"In relation to any IETF standard incorporating the technology in the  
ZRTP
specification ("ZRTP Technology"), Philip Zimmermann (together with his
successors and assignees, “PRZ”) will grant a royalty-free, non- 
exclusive
license to Qualified Parties to use the ZRTP Technology solely to the  
extent
necessary to implement and practice such IETF standards in strict  
conformance
with the IETF standards.  As used herein, Qualified Parties means a  
party who
has not, does not and will not assert, in litigation or otherwise,  
including in
licensing discussions, any patent or other intellectual property  
right against

(Continue reading)

Colin Perkins | 26 Oct 2006 17:21

Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt]


[This is being sent to avt <at> ietf.org with a bcc to rtpsec; response to  
avt please since that is the group responsible for RTP]

I have reviewed draft-zimmerman-avt-zrtp-02.txt and have some serious  
concerns regarding the way ZRTP integrates with the RTP architecture.  
In particular, I believe this draft misuses both the RTP  
synchronisation source (SSRC) and the RTP header extension mechanism.

1) Misuse of the RTP synchronisation source (SSRC): the latest draft  
states (section 5) that ZRTP endpoints "MAY use a different SSRC for  
ZRTP messages than for RTP media" since this allows "for very loose  
coupling between the ZRTP application and the RTP media application".  
This violates RFC 3550 in several fundamental ways:

a) RFC 3550 specifies that the SSRC identifies the "source of a  
stream of RTP packet" and requires receivers to group packets  
according to SSRC for playout and other processing. Using a separate  
SSRC for ZRTP and RTP data belonging to a single flow breaks playout  
buffer operation, and requires receivers to ignore the RFC 3550 rules  
on source identification.

b) If a different SSRC is used for ZRTP packets than for RTP packets,  
it is not possible to differentiate packets from different  
participants, unless unicast sessions with only two parties are  
assumed. This breaks multicast and multiparty RTP, as well as mixers  
and translators operating according under RFC 3550.

c) Use of a different SSRC for ZRTP and RTP packets can disrupt the  
correct operation of the RTP collision and loop detection algorithm.

(Continue reading)

Dan Wing | 28 Oct 2006 01:02

Picon

alternate RTP profiles in SDP offer/answer

draft-ietf-avt-profile-savpf-09 mentions, in several places, how ports can
be overloaded and grouping can be used to specify RTP/SAVP and RTP/SAVPF in
the same offer.  The suggestions in draft-ietf-avt-profile-savpf-09 appear
to have the drawbacks that Flemming describes in section 3.1 and 3.5 of
draft-andreasen-mmusic-sdp-capability-negotiation-01.  It seems ill-advised
for AVT to publish a document encouraging use of mechanisms with these
drawbacks, unless MMUSIC agrees with this decision.

Considering that the upcoming IETF has two individual contributions in
MMUSIC on this topic, draft-andreasen-mmusic-sdp-capability-negotiation-01
and draft-kaplan-mmusic-best-effort-srtp-01, I don't believe there is
consensus within MMUSIC of which approach to take.

Can Joerggand Elisabetta discuss the technique proposed in
draft-ietf-avt-profile-savpf-09 at the upcoming MMUSIC meeting?  Or can we
perhaps have a joint presentation by all five authors so that MMUSIC can
make an informed decision on this important topic?

-d

> 	Title		: Extended Secure RTP Profile for 
>                   RTCP-based Feedback (RTP/SAVPF)
> 	Author(s)	: J. Ott, E. Carrara
> 	Filename	: draft-ietf-avt-profile-savpf-09.txt
> 	Pages		: 17
> 	Date		: 2006-10-25
> 	
>    An RTP profile (SAVP) is defined for secure real-time
>    communications, and another profile (AVPF) is specified to provide
>    timely feedback from the receivers to a sender.  This memo defines

(Continue reading)

Francois Audet | 28 Oct 2006 02:13

RE: alternate RTP profiles in SDP offer/answer

I fully support Dan's suggestion.

It seems to me that a significant fraction of
draft-ietf-avt-profile-savpf-09
is really MMUSIC material, and does overlap with the two drafts that 
Dan listed.

I also support the suggestion that all the parties try to collaborate
on a joint presentation of the issues.

> -----Original Message-----
> From: Dan Wing [mailto:dwing <at> cisco.com] 
> Sent: Friday, October 27, 2006 4:02 PM
> To: mmusic <at> ietf.org; 'Joerg Ott'; carrara <at> kth.se
> Cc: 'Flemming Andreasen'; 'Hadriel Kaplan'; Audet, Francois 
> (SC100:3055); ietf-rtpsec <at> imc.org
> Subject: alternate RTP profiles in SDP offer/answer
> 
> draft-ietf-avt-profile-savpf-09 mentions, in several places, 
> how ports can be overloaded and grouping can be used to 
> specify RTP/SAVP and RTP/SAVPF in the same offer.  The 
> suggestions in draft-ietf-avt-profile-savpf-09 appear to have 
> the drawbacks that Flemming describes in section 3.1 and 3.5 
> of draft-andreasen-mmusic-sdp-capability-negotiation-01.  It 
> seems ill-advised for AVT to publish a document encouraging 
> use of mechanisms with these drawbacks, unless MMUSIC agrees 
> with this decision.
> 
> Considering that the upcoming IETF has two individual 
> contributions in MMUSIC on this topic,

(Continue reading)

Joerg Ott | 28 Oct 2006 10:19

Picon

Re: alternate RTP profiles in SDP offer/answer

Dan,

what you claim to be a problem here has been removed from the SAVPF
spec for this very reason.  -08 had -- by accident -- some remnants
in that were taken out in -09.  Should there be an oversight left in,
then please be precise of what you mean and we will be happy to
fix this.

To quote from present -09:

    If alternative RTP profiles are to be specified for a single RTP
    session, each alternative needs to be included on a separate media
    line in SDP.  However, with only basic SDP, it is not possible to
    communicate that the two m= lines are meant as alternatives (as
    opposed to specifying different media sessions of the same type).
    A mechanism to indicate semantic equivalence between the individual
    sessions and ensure that any receiver only joins one of them, such
    as the grouping framework [9], is being defined in the MMUSIC WG.

 From the mere authorship of the spec, it should become clear that
there is a close interaction with what MMUSIC does.

I must admit that I am somehwat surprised and not particularly
amused about your seocnd-guessing below.

Joerg

> draft-ietf-avt-profile-savpf-09 mentions, in several places, how ports can
> be overloaded and grouping can be used to specify RTP/SAVP and RTP/SAVPF in
> the same offer.  The suggestions in draft-ietf-avt-profile-savpf-09 appear

(Continue reading)

Francois Audet | 30 Oct 2006 19:36

RE: alternate RTP profiles in SDP offer/answer

Hi Joerg,

It looks like we may have misinterpreted the concept of "alternatives"
in the draft.

The drafts left us with the impression that it was indeed endorsing the
idea 
of port overloading. We had assumed that "alternatives" were meant to
denote
backward compatibility with UAs that did not support SAVPF.

I guess the paragraph that you quoted below clarifies it, but it may not
be 
totally obvious to the reader that the mechanism in this draft suffers
from
the exact same problem described in the 2 drafts than Dan listed.

Perhaps a simple statement upfront to clarify it would help.

For example, the  first paragraph of Page 7 currently state:

   Different RTP profiles MAY be used in different media sessions.
   For negotiation of a media description, the four profiles AVP,
   AVPF, SAVP, and SAVPF are mutually exclusive.  Note, however, that
   SAVP and SAVPF entities MAY be mixed in a single RTP session (see
   section 4).  Also, the offer/answer mechanism MAY be used to offer
   alternatives for the same media session (e.g. using the same
   transport parameters) and allow the answered to choose one of the
   profiles.

(Continue reading)

Dan Wing | 30 Oct 2006 23:58

Picon

RE: alternate RTP profiles in SDP offer/answer

> what you claim to be a problem here has been removed from the SAVPF
> spec for this very reason.  -08 had -- by accident -- some remnants
> in that were taken out in -09.  Should there be an oversight left in,
> then please be precise of what you mean and we will be happy to
> fix this.

Thanks.  I'm sorry for not noticing, until now, this AVT document was
normatively specifying SDP behavior for SAVPF.  Here are my comments about
the MUSTs in the document that may interfere with the I-Ds on best-effort
SRTP:

-----

1.  Section 3.3.1 says:

  If supported, the answerer SHOULD prefer a secure profile over 
  non-secure ones.

and later says:

  If a media description in an offer uses SAVPF and the answerer 
  does not support SAVPF, the media session MUST be rejected.

Based on -savpf-09's defintion of "media session", this means the entire
RFC3388 group has to be rejected.  This means an RFC3388-grouped offer with
SAVPF and SAVP, sent to an answerer that understands RFC3388 and SAVP (but
the answerer doesn't implement SAVPF), would have to be rejected by the
answerer.  I don't believe this is your intent.  I suggest deleting:

  If a media description in an offer uses SAVPF and the answerer

(Continue reading)

Hadriel Kaplan | 31 Oct 2006 19:54

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


Howdy,

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.

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.

-hadriel

> -----Original Message-----
> From: owner-ietf-rtpsec <at> mail.imc.org [mailto:owner-ietf-

(Continue reading)

Group

gmane.ietf.rtpsec.

Advertisement

Search Archive

Page

1 | 2 | 3

Articles in period: 20

October 2006

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

DTLS-SRTP Key Transport (16 Feb 2008)
Status updated on discussions with 3GPP on RTPSec topics (13 Feb 2008)
One "record" per datagram when the "use_srtp" extension is in effect (13 Jan 2008)
One "record" per datagram when the "use_srtp" extension is in effect (13 Jan 2008)
SRTP Key Disclosure (21 Nov 2007)
dtls-srtp-kt (12 Nov 2007)
Security Analysis of Voice-over-IP Protocols (5 Sep 2007)
Sending SIP packet over TCP (16 Jul 2007)
Sending SIP packet over TCP (16 Jul 2007)
FW: [MMUSIC] ICE-TCP issue: DTLS-SRTP over TCP? (10 Jul 2007)
FW: IPR Statement RE: draft-wing-sip-identity-media-00.txt (4 Jul 2007)
SIP Identity using Media Path (2 Jul 2007)
IVR/CallingCard scenario (16 Jun 2007)
Moving on ... (14 Jun 2007)
Media Security Requirements Draft (29 May 2007)
Media Security Requirements Draft (29 May 2007)
Plan for moving forward (11 May 2007)
[Fwd: I-D ACTION:draft-wing-media-security-requirements-02.txt] (20 Apr 2007)
Comments for (6 Apr 2007)
Switching between secure and non secure ZRTP sessions and SRTP ROC syn (29 Mar 2007)
draft RTPSEC minutes posted (23 Mar 2007)

Archives

2	February 2008
4	January 2008
5	November 2007
2	September 2007
37	July 2007
120	June 2007
4	May 2007
25	April 2007
312	March 2007
43	February 2007
20	January 2007
51	November 2006
20	October 2006
11	September 2006
44	August 2006
6	July 2006

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template