RE: draft-lehtovirta-rtpsec-infra-00

["Dan Wing" <dwing@xxxxxxxxx>]

> You understood it right. However, I am not as convinced that 
> all methods do support this requirement. E.g., how would ZRTP 
> support a PSTN GW.  How would a user be able to read the SAS 
> as a PSTN user? 

Right, the SAS can't be displayed and the user can't read it to
the other user.  Of course, once the PSTN is involved there no
longer is end-to-end encryption, so even if you could read the
SAS it (and SRTP) only protects the VoIP portion of the call
leg.

But, to provide some security in such a situation zrtp-03
introduced the ability to sign the exchange using a 
certificate.  This certificate could be exchanged in, or
referenced in, SIP signaling (although how this is done isn't 
specified in zrtp-03).  By doing this, a PSTN gateway could
perform SAS validation on behalf of the user who cannot
perform SAS validation.

A similar technique could be used when modems or fax machines
are involved; they also cannot recite the SAS.

> There may be other problems with the some of the other 
> solutions as well, depending on mode used etc, and how 
> credentials are tied to user. This may very well deserve 
> some investigations.

Ok.  I'll figure out how to capture that requirement and
hope to include it in the slide deck in Prague.

> >     >  4.  Using shared keys to provide media security
> >     >
> >     >     There are environments where the communicating
> >     >     endpoints set up shared keys with the network
> >     >     infrastructure.  An example of such environment is the
> >     >     widely deployed GSM system and its 3G successor, the
> >     >     UMTS.  It would be beneficial if the shared keys
> >     >     between the endpoints and the network infrastructure in
> >     >     these kind of systems could be re-used to provide
> >     >     shared keys also between the communicating endpoints.
> >     >
> >     >     Therefore, it might be justified to consider using
> >     >     shared keys in addition to public keys to provide media
> >     >     security in some environments.
> > 
> > I'm not really clear what you mean by 'network infrastructure'.
> > From my viewpoint, which is biased based on my personal 
> > experience and my employer, network infrastructure are things 
> > like routers and Ethernet switches.  Those would not be 
> > involved with SRTP keying.  I know you have different 
> > elements in mind, and I am guessing you're referring to 
> > terminating SRTP within the network and using UMTS's 
> > inherient security over-the-air to the handset, rather than 
> > SRTP over-the-air to the handset?
> 
> Not exactly. With network infrastructure in this context I 
> mean network entities hadling the keys e.g. a server called 
> Authentication Center in GSM which shares a long term key with 
> a smart card that is in the handset.  This long term key is 
> used to derive session keys which are then used secure the 
> communication sessions between the handset and the
> network.  
> 
> The intention of this section is still to use SRTP end-to-end 
> between the endpoints.  But, in some environments, there is a 
> long term shared key available in the handset and in the 
> network server, it might be justified to consider
> key management methods where this long term shared key could 
> be re-used to provide a shared key to the SRTP endpoints. 

Ok, thanks for the explanation.

I'm not sure how to use that in a system where one endpoint 
belongs to that system and the other endpoint is, say, my 
802.11 PDA running a softphone (that is, my PC doesn't have 
an iSIM and is not using the GSM network).

> >     >  5.  Setting up media security with the help of a third
> >     >      party
> >     >
> >     >     Setting up a secured connection to an arbitrary peer
> >     >     requires that the communicating entities have in some
> >     >     way agreed on key management credentials, E.G. shared
> >     >     keys or certificates.  From scalability point of view
> >     >     it is in practice not feasible to achieve this to an
> >     >     arbitrary peer without the help of some third party
> >     >     providing the credentials.
> >     >
> >     >     To enable a scalable solution that allows to set up a
> >     >     secure connection to an arbitrary peer seems to require
> >     >     the help of some third party.
> > 
> > I don't understand what functions that 3rd party would do -- are
> > you thinking of a Certificate Authority, or are you thinking of
> > something else?
> 
> Certificate Authority is one example, or if shared keys are used, then
> this could be a server providing the shared keys.

For the shared key case, consensus in Montreal was to defer the shared 
key problem unitl later.  The hum, as I recall, was something like
70%/30%, where 70% wanted to defer shared keying until later and do
unicast, point-to-point keying now.
 
> >     >  6.  Termination of media streams in different devices
> >     >
> >     >     In some cases, different media streams might be
> >     >     terminated in different devices.  For example, the
> >     >     video part of a multimedia session could terminate in
> >     >     one device, while the audio part would terminate in
> >     >     another device.  It should be possible to set up media
> >     >     security efficiently in such scenarios.
> > 
> > I agree this is a requirement, but I believe all of the existing
> > key exchange mechanisms support this requirement, as do all of
> > the new generation of key exchange mechanisms.  Do you feel 
> > they are lacking in this support?
> 
> I'm not fully convinced that all mechanisms discussed so far 
> efficiently solve this problem. I think this is an area that 
> may deserve further analysis. 

In http://www.imc.org/ietf-rtpsec/mail-archive/msg00401.html I 
provided example SDP for how this could be done.  Please let me
know if there was an error or oversight on my part in that message.  

The hard thing, to me, seems to be coordinating call signaling 
between the two devices so that there is one SDP and one SIP 
answer.  

Assuming both the offerer and the answerer support sdescriptions
and ZRTP, it seems you could even send your audio to a device 
that runs sdescriptions and your video to a device that supports 
ZRTP (or any other combination, including MIKEYv2 or DTLS-SRTP),
as each "m=" line is handled separately by SDP and by the SRTP 
key exchange mechanisms.

-d