Subject: [MMUSIC] RE: [Sip] Removing security preconditions from manyfolks

From: "David R. Oran" <[email-masked]>
Date: Sun, 3 Mar 2002 19:31:54 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Peterson, Jon
> Sent: Monday, February 25, 2002 5:12 PM
> To: 'Flemming Andreasen'; Gonzalo Camarillo
> Cc: sip; mmusic; Fredrik Lindholm (ERA); Jonathan Rosemberg; 
> [email-masked]
> Subject: RE: [Sip] Removing security preconditions from manyfolks
> 
> 
> One of the reasons why you need a special preconditions flag 
> (and the rest of the manyfolks apparatus) for QoS is because 
> you use a separate protocol (like RSVP) to negotiate the 
> reserved path end-to-end. Nothing about SIP or SDP or RTP 
> would otherwise tell you that reservation of the path has 
> been expected or achieved. IMHO, this would be unwise, and 
> probably infeasible, for a security mechanism. The use of 
> sRTP e2e will be obvious to the respective user agents, for 
> example, and the parameters of the sRTP session should be 
> correlated easily to information in SDP or SIP so the UAs can 
> have verifiable expectations about the session's security. I 
> think all e2e media security mechanisms will probably need to 
> have these sorts of properties (regardless of whether or not 
> you use RTP, secure media will still be secured, and that 
> will always be obvious to the user agents). Therefore, I 
> think that a separate preconditions flag for security should 
> always be superfluous for any useful security mechanism. I 
> think we can ditch it.
>
This is not at all clear to me. What if I want to use IKE or Kerberos to
do the key exchange? What if the key exchange is not in fact tied
directly to the session signaling, but you need to verify via the call
signaling that cached keys have not been thrown away?
 
> That much said, I don't necessarily oppose the IANA 
> registration suggested by Flemming below, although I think as 
> a motivation for it we'd need to understand, generally 
> speaking, what sort of other preconditions people might find 
> desirable.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:[email-masked]]
> > Sent: Sunday, February 24, 2002 9:42 PM
> > To: Gonzalo Camarillo
> > Cc: sip; mmusic; Fredrik Lindholm (ERA); Jonathan Rosemberg; 
> > [email-masked]
> > Subject: Re: [Sip] Removing security preconditions from manyfolks
> > 
> > 
> > Not all media streams use RTP or SRTP, and there are other security 
> > mechanism than MIKEY. While I don't feel strongly about keeping the 
> > "security" precondition, I don't see much gained from removing it. 
> > Perhaps more importantly, since you are going to break the existing 
> > manyfolks-03 draft mechanism anyway, it would make sense to 
> make the 
> > preconditions extensible (with suitable IANA registration 
> procedures 
> > of course).
> > 
> > -- Flemming
> > 
> > 
> > Gonzalo Camarillo wrote:
> > 
> > > Hi,
> > >
> > > we are thinking of removing security preconditions from
> > manyfolks. Right
> > > now manyfolks handles QoS and security preconditions. 
> However, with 
> > > MIKEY, this feature seems useless to establish secure channels.
> > >
> > > If somebody thinks that removing security preconditions
> > from manyfolks
> > > is a bad idea, please speak up.
> > >
> > > Regards,
> > >
> > > Gonzalo
> > > --
> > > Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> > > Columbia University                  Mobile:  +358 40 702 35 35
> > > 472 Computer Science Building        Fax   :  +358  9 299 30 52
> > > 1214 Amsterdam Ave., Mail Code 0401  
> http://www.hut.fi/~gonzalo New 
> > > York, NY 10027
> > > USA    
>                           [email-masked]
> > >
> > > _______________________________________________
> > > 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
> > 
> > --
> > Flemming Andreasen
> > Cisco Systems
> > 
> > 
> > 
> > _______________________________________________
> > 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
> > 
> 
> _______________________________________________
> 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
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 5 Mar 2002 08:59:29 -0600

Some notes below.

Jon Peterson
NeuStar, Inc.

> From: David R. Oran [mailto:[email-masked]]
> Sent: Sunday, March 03, 2002 4:32 PM
> To: 'Peterson, Jon'; 'Flemming Andreasen'; 'Gonzalo Camarillo'
> Cc: 'sip'; 'mmusic'; 'Fredrik Lindholm (ERA)'; 'Jonathan Rosemberg';
> [email-masked]

Well, agreed that without a particular security mechanism in mind the issue
becomes cloudier. I guess this might also boil down to what exact occurrence
or set of occurrences would constitute the 'security' precondition being
satisfied; it sounds above like you believe the possession of valid keys for
encryption and decryption would be such a prerequisite. Undoubtedly, in the
most literal-minded sense, having the other party's session key is a
prerequisite for sending secured media; I can imagine a number of other
potential prerequisites (like mutual e2e authentication, for example).

My point was that one cannot start sending secure media until one has
received the session key from the other party - and also, that it will be
obvious, when a party receives a media packet, whether or not that packet is
secured (and what key was used to secure it). RSVP, however, is a very
different story. Nothing about how you are going to send a packet changes
after your reservation has completed. Nothing about a media packet that you
have received is necessarily going to suggest to you that this packet
crossed the network over a reserved bandwidth path. So I think there is
actually a fundamental difference between the needs of reservation and
security, regardless of whether or not the key exchange takes place in SIP.
I understand why a COMET and a token in the SDP is useful for reservation,
but for security, if they serve anything like the same purpose they seem to
serve for reservation, I imagine they would superfluous.

That much said, I have no doubt that one could devise a security mechanism
that relied on an SDP preconditions flag for some purpose. I suspect though
that a simple flag wouldn't ever really suffice, and that you'd probably
want something that at least characterized the expected security, or the
exact preconditions which have or have not been satisfied. This I feel would
likely be outside the scope of manyfolks, and moreover specific to some
particular media security scheme.