AW: pre-established key mode as additional requirement?

["Dittmann, Werner" <werner.dittmann@xxxxxxxxxxx>]

> -----Ursprüngliche Nachricht-----
> Von: owner-ietf-rtpsec@xxxxxxxxxxxx 
> [mailto:owner-ietf-rtpsec@xxxxxxxxxxxx] Im Auftrag von David R Oran
> Gesendet: Dienstag, 20. Februar 2007 13:46
> An: Dan Wing
> Cc: ietf-rtpsec@xxxxxxx
> Betreff: Re: pre-established key mode as additional requirement?
> 
> 
> 
> On Feb 19, 2007, at 9:07 PM, Dan Wing wrote:
> 
> >
> > I would like to see if there is consensus for a new 
> requirement for  
> > RTPSEC.
> >
> > Specialized devices may need to avoid public key operations or
> > Diffie-Hellman operations because of the computational cost or  
> > because of
> > the additional call setup delay.  For example, it can take 
> a second  
> > or two
> > to perform a Diffie-Hellman operation in certain devices.  
> Examples  
> > of these
> > specialized devices would include some handsets, intelligent SIMs,  
> > PSTN
> > gateways, and SBCs.  For the typical case because a phone call  
> > hasn't yet
> > been established, ancillary processing cycles can be utilized to  
> > perform the
> > PK or DH operation; for example, in a PSTN gateway the DSP (which  
> > isn't yet
> > involved with typical DSP operations) could be used to perform the
> > calculation, so as to avoid having the central host processor  
> > perform the
> > calculation.  Some devices, such as SBCs, handsets, and 
> intelligent  
> > SIMs do
> > not have such ancillary processing capability.
> >
> > Thus, it seems a useful optimization to securely set up a call the  
> > first
> > time with a remote endpoint, and thereafter, when communicating  
> > with the
> > same remote endpoint, to leverage the DH or PK that was performed
> > previously.
> 
> > Thoughts?
> >
> It seems eminently reasonable to support key management schemes for  
> rtpsec that can leverage cached/stored keying material from prior  
> sessions to derive new keys for the current session without 
> requiring  
> expensive cryptographic authentication operations.
> 
> Are you thinking of this as a MAY, a SHOULD, or a MUST?
> 
> Would you consider the TLS "session restart" machinery as qualifying  
> to meet this requirement?
> 
> 
> > -d

Another solution to prevent DH computation during seesion set up:
precompute some DH key pairs and store them. During session setup
randomly select on of the pairs and use it. This precomputing could
be done duting idle times.

A previously negotiated key is a "shared secret" between both parties.
If this shared secret shall survive a session then some additional
requirements pop up:
- both parties MUST be sure that they are talking to the same party/client 
  when they set up a new session. Otherwise the shared secret would be no 
  longer a "secret". 
- the shared secrets must be stored in save places, ideally protected by
  some password (encrypted?). 
- User notification that a secret was stored?
- how long would such a shared secret be valid? Forever?

Such a mechanism and the underlying protocols must be designed very
carefully, otherwise no security can be guaranteed. Also keep in mind how
an user would handle it, which implications this might have to communications
clients etc.

Having this type of shared secret during a session only, for example to setup
another media connection between the parties, would be a good idea. That way
only one costly DH/PK computation may take place at the begining, during
the session reuse some precomputed/negotiated keys and security data to
setup additional SRTP connections.

Regards,
Werner