Subject: RE: [MSEC] draft-blom-mm-kmgt-00.txt

From: Ran Canetti <[email-masked]>
Date: Thu, 6 Sep 2001 01:03:08 -0400

Fredrik,

Sorry for the long delay. Here are some responses to yours.
I think that the most important issue is the first one, ie the 
deployment of the timestamps in the internet environment.

Best,

Ran

> 
> From: "Fredrik Lindholm (ERA)" <[email-masked]>
> Date: Mon, 27 Aug 2001 16:39:43 +0200
> 
> 
> * One of the design choices has been to use timestamps
> even though it has limitations. We are aware that we must add
> clarifications of its use in different scenarios, the
> security implications etc. We like this approach because it gives us the
> possibility to let the source "push" down keys very
> fast and because it gives the possibility to integrate/piggy-back the
> protocol in the call control, e.g. SIP and RTSP. 

I certainly appreciate the benefits of using timestamps. 
But in order to understand what is being suggested I'd be interested 
in hearing more on the parameters you had in mind with respect 
to deployment. How large would you expect the time interval to
be in a typical connection? say, between a source and a desktop computer, or
between a source and a roaming laptop, or a hand-held device such as a pda
or a cell-phone? how synchronized would your solution require the devices to
be? (Note that here we not only talk about time synchronization from the
beginning of a session, but rather global time synchronization.)

That these questions are arguably at the heart of the realizability of the 
method...

> * For one way authentication our public key scheme
> needs 1/2 round. This can't be achieved with a scheme that requires
> mutual party input for the key derivation (such as the revised public key). 

Mutual input to the key is a rather minor concern, and is not really the
issue. What prevents the public-key mode (as well as the other modes of IKE) 
from being "1/2 round" is a number of things, perhaps the most basic of which 
is the need to guarantee freshness of the key without using timestamps.

> * We do not mandate forward secrecy due to the
> computational burden, but we included the DH to be able to provide it as
> optional. Note that there often exists constrains on
> call setup time and the delay budget is essentially filled by the transport
> of bits itself.

That's absolutely fine. I'd add language to the drafts explaining that
what DH buys is PFS and discussing the price and tradeoffs.

> 
> SIP scenario
> 
> What we tried to describe in the SIP scenario was that
> even though it might be technical possible to have an end-to-end
> protection of the SIP signaling, this will probably not
> be done in many practical implementations (due to intermediate nodes
> etc.). Instead of always relying on the security of SIP
> (or RTSP) we believe that we need our own protection which should be
> independent of the transport protocol used. 

I see. That's a valid and good point. (Somehow I didn't understand it from
the text. Perhaps it should be clarified.)

> 
> ID protection
> 
> Your points are definitely valid. But our main concern
> was not to provide anonymity at the extra cost of additional
> roundtrips. However, some level of identity protection
> can be given, e.g. in the pre-shared key version. In this case, of
> course, the two calling parties know the identity by
> the other (e.g. by using pseudonyms). In the public key case we do
> provide identity protection by allowing the
> ID/Certificate to be encrypted (this will however open DoS problems). The
> initiator's identity will then be protected as well as
> the responder's (this will of course require that the responder knows what
> private key to decrypt with). 

This is good against attackers that only listen on the line.
Your protocol does not protect the identity of the initiator
(typically, the client) against active attackers that impersonate the 
receiver. This may be ok/acceptable to you, but it should probably be said
explicitly.

> Groups
> 
> We had as an application, a multimedia session in which
> you dynamically may add new streams. To us it is then natural to make
> the source the membership controller. 

i see. How do you envision the process of joining a session/adding streams?
how (and to whom) would a new receiver express its wish to join the session?
how will it learn which stream to listen to?

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec