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: Sun, 10 Jul 2005 15:17:31 -0500

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

Right, it probably does need more coverage. However, I'd like to 
cover it without getting into the turf of the protocols that
would provide that functionality.

For example, it could be certificates attached to responses as described
in RFC 3261, or it could be the SIP Identity-draft.

I'll try to work with Cullen on that one.

> > This case is not addressed today by the current mechanism (MIKEY PSK
> > and
> > SDESC)
> 
> 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.  

Yeah, it makes sense to me that you would consider doing this. I had the
same
tought that something similar to what we are proposing could apply to
sdesc 
as well.

I think the case where initiator can not "strongly identify the 
responder" before the message is sent applies to SDESC with S/MIME just
as
much as it applies to MIKEY-PSK (it's when there is retargeting
to another AOR/Subject).

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

That's the idea: it is when your specifically want to allow retargeting
(which is unpredictable: even if you "try to get it" before sending the
i_message, it may still change). We have to deal with this: it is very
basic 
SIP. It happens all the time, and it's not going away.

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

It only makes a difference if you assume that the sender is capable of
receving 
and playing all the early media streams from the different branches of
the fork 
simultaneously, which I have yet to see anybody do, and even if anybody
did, the
cacophony would most look more like a design flaw to the user than
design intent.

In other words, early media doesn't work with forking. But, this is
exactly the
type of thing that I don't think belongs in the msec group...

That being said, point taken: we should explain the limitations it has
with point to multipoint.

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

Makes sense to me: it would be useful features to add to SDESC.

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

We'll look into that. 

Thanks again: good input.

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