Subject: RE: [MSEC] Some comments onhttp://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt

From: "Francois Audet" <[email-masked]>
Date: Sat, 9 Jul 2005 14:00:15 -0500

Hi Mark, thanks for your comments.

(I'll limit my reply to the SIP aspects you are refering to).

See below on the SIP aspects.

> 3.  But you do support a group key, in the msec sense, and I 
> think the  
> following security consideration is really important for group  
> communications:
>    "When using the RSA-R mode, the Responder may turn out to 
> be different
>     from who the Initiator sent the MIKEY message to.  It is the
>     responsibility of the Initiator to verify that the identity of the
>     Responder is acceptable if it changes from the intended Responder,
>     based on its policy, and to take appropriate action based on the
>     outcome.  In some cases, it could be appropriate to accept any
>     Responder's identity; in other cases, a blacklist or a 
> whitelist may
>     be appropriate."
> 
>     This needs an example and maybe a security improvement.  
> First, SIP  
> forking is an example.  I don't think RFC 3880 is well suited 
> to SIP on  
> the general Internet, but it will be used for SIP (see  
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ex
> t-15.txt)  
> maybe in some contexts (3GPP?).  SIP calls fork and RFC 3830  
> implementations may not handle SSRC collisions well when a 
> fork occurs.  
>   I think rsa-r should address this problem directly and the 
> current I-D  
> should mention it.

I don't see any justification for the statement that 3830 is not well
suited to SIP on the general internet.

In fact, one of RSA-R's goal is specifically to target to deal with 
a very common case in SIP:

  You wish to establish a session with sRTP media, and you don't "know"
in 
  advance who the responder will be (because of retargeting), but you
still 
  want the media to be encrypted using sRTP. This is very typical
  for "telephony" for example where you may wish to have a policy that 
  all calls have encrypted media, regardless of who answers. The text
you
  quote discusses the security implications of this, specifically if the

  initiator wants to use blacklist, whitelists, and so forth.

This case is not addressed today by the current mechanism (MIKEY PSK and
SDESC)
which focuses on another scenario, which is when you want to established
a secure 
sRTP media session and/or encrypted MIME bodies with a  specific
individual (or at
least a specific Address Of Record). 

Those two cases are quite different and address different scenarios.

PS: Can you clarify what you mean by the SSRC problem, and specifically
why it would be different for RSA-R versus sdesc or PSK (and thus
covered
in this I-D)? I must be missing something.

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

---

From: Mark Baugher <[email-masked]>
Date: Sun, 10 Jul 2005 10:01:16 -0700

hi Francois,

> Hi Mark, thanks for your comments.

You're welcome.
> See below on the SIP aspects.

...
> suited to SIP on the general internet.

mikey requires synchronized clocks, which are not generally available 
on the Internet, i.e. mikey assumes a level of homogeneity that does 
not exist on the Internet.
>   initiator wants to use blacklist, whitelists, and so forth.

I have another question about rsa-r and the presence of a certificate 
authority to vouch for an initiator or responder.  Such a thing doesn't 
exist today and I'm curious to know if it's a reasonable service to 
expect in the near future?  I think you need a little more coverage in 
the Security Considerations section to explain under what conditions an 
r_message would be authorized by the initiator, since the responder may 
not be the entity originally invited.
> This case is not addressed today by the current mechanism (MIKEY PSK 

I agree. Flemming, Dan and I have been discussing adding a new exchange 
where the responder provides the keymat.  That's still different from 
rsa-r, however, because rsa-r does not stongly identify the responder 
before the message is sent.  It might be useful to allow the initiator 
to offer a certificate without knowing the responder's *if you can 
strongly authenticate AND authorize the responder when the r_message 
arrives*  I think this might be hard to do without a global PKI.  It 
also begs the question:  If it's possible to validate a cert after it's 
received in an r_message, why can't you get it prior to sending the 
i_message?

> least a specific Address Of Record).

As I said in my previous note, sdescriptions supports n-pairwise as 
well as pairwise (between specific individuals) sessions.  That's a SIP 
requirement, e.g. to support forking.  The difference between 
sdescriptions and rsa-r/mikey is that each sdescriptions sender sends 
its own master key.  We wanted to keep it simple.  I think a useful 
sdescriptions feature might be for either the responder or the 
initiator to give the other a master key.  sdescriptions also needs a 
diffie-hellman exchange.  We (or at least I) plan to add group-security 
features to the next version of sdescriptions.  We postponed it for now 
because SRTP's is not well-suited to group/multicast applications at 
the present time owing to the problem of SSRC uniqueness.

> in this I-D)? I must be missing something.

Sure.  If SSRCs are not unique in an SRTP session, the encryption will 
eventually be compromised owing to One-time-pad reuse (e.g. known 
plaintext leads to disclosed ciphertex).   sdescriptions avoids this by 
requiring each side to use its own master key.  mikey avoids this by 
including the SSRC (and the ROC) in the signaling.  We have seen 
applications, however, that change the SSRC "on the fly" without 
signaling.  Tight coupling of RTP with the key management, moreover, is 
hard to achieve since both SRTP key mgt schemes hooks into the SDP or 
signaling state machine.  The dangers are worse in forking since the 
forked responders can collide and won't know that they collided (or 
that they were even forked, I am told) because this is n-pairwise and 
not a group communications scenario.

At every point when you get something other than one endpoint 
communicating with exactly one endpoint, there is an SSRC collision 
problem looming.

Mark