Re: AW: pre-established key mode as additional requirement?

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

"Dittmann, Werner" <werner.dittmann@xxxxxxxxxxx> writes:
>> 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.

This doesn't help as much as you'd like because you still need to
compute ZZ. This can actually be slower because you can't use
a table of precomputed g squares. Also, it doesn't work if there
are more than a few groups, since you don't know what shares to
precompute.


> 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". 

A properly implemented mechanism will require the other side to prove
possession. 


> - the shared secrets must be stored in save places, ideally protected by
>   some password (encrypted?). 

True. Most implementations accumulate quite a bit of secret stuff they
need to store securely. What's appropriate depends on the deployment
environment.


> - User notification that a secret was stored?

I don't see that this is necessary at the UI level. Obviously, your
toolkit should tell you what it is doing.


> - how long would such a shared secret be valid? Forever?

This was a controversial issue in the design of TLS because there's
no actual reason why a properly designed mechanism can't be used
essentially indefinitely, like a manually established secret key
is. The concerns are about policy, windows of exposure, and PFS.


> 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.

As I said above, the users don't have to know. In TLS, for instance, 
you typically design the APIs to provide all the information that you
would have if you hadn't done resumption, with another API mechanism
to determine if the session was in fact resumed.

-Ekr