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

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Mon, 27 Aug 2001 16:39:43 +0200

Mark, Ran, 

Thanks for the comments.

I'll try to answer some of your questions and comments by the following statement:
* Our main concern is (as Mark pointed out) security of media streams (i.e. SRTP) not the security of the call control such as SIP and RTSP (we understand that we need to clarify the relationship between call control and media security).
* 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. 
* 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). 
* 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.
* It is our intention to separate the key management protocol from the security protocol (even though we right know only have SRTP). 

DoS

Due to the nature of the protocol (i.e. that it is meant to be integrated in e.g. SIP) we do not check the validity of the originator's address. This may however be done by the transporting protocol (I would even recommend this). But if this is not done by the transporting protocol, this will lead (in the worst case) to one signature verification each time a "valid" message arrives. Still, we should probably add this in the security considerations. 

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. 

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

Re-keying

Note that we clearly distinguish between re-keying and refresh. The latter being deriving a new key without any extra communication. 

Life time

The fact that the key lifetime etc. may differ depending on the security protocol makes it impossible to specify it in the key management draft. However, we could provide recommendations on a more general level. Note that in SRTP we specify such limits for SRTP and we believe that other security protocols designers should do the same.

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. 

The others security related comments about what should be included in hashes etc. are of course valid and we need to take these into account, thanks.

Once again, thanks for the comments and you are more than welcome to send more. 

Best Regards,
Fredrik

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