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

From: Mark Baugher <[email-masked]>
Date: Sat, 9 Jul 2005 11:01:49 -0700

hi
   Thanks for posting draft-ietf-msec-mikey-rsa-r-00.txt.  I have a few  
comments.

1.  It's nicely written and clear.  The last sentence below, however,  
is not accurate:
   "The DH mode or the DH-HMAC mode of MIKEY might be useful in cases
    where the Initiator does not have access to the Responder's exact
    identity and/or CERT.  In these modes, the two parties engage in an
    authenticated DH exchange to derive the TGK.  However, the DH modes
    have higher computational and communication overhead compared to the
    RSA and the PSK modes.  More importantly, these modes are unsuitable
    for group key distribution."

   I believe that msec key distribution typically RFCs use DH as part of  
group key distribution viz. http://www.ietf.org/rfc/rfc4046.txt.  So  
this last sentence is wrong.

2. Further on:
   "Note that in the MIKEY-RSA mode (as in case of the PSK mode), the
    Initiator proposes the RTP security policy, and chooses the TGK.
    However, it is also possible that the Initiator wants to allow the
    Responder to specify the security policy and send the TGK.  This
    would be the case in some multicast and group conferencing  
scenarios."

    I think you're absolutely right but I would add a little bit here.   
MIKEY modes are today pairwise and your I-D adds a mode to make it  
possible for a bridge, mixer, mcu, server, or other type of controller  
to hand the end-system a group key.  Did I get that right?  I think  
it's true that MIKEY (RFC 3880) supports a pairwise crypto context and  
mikey-rsa-r supports a group crypto context.  That's fine, but what  
about an n-parwise crypto context?  As a footnote, I would add that  
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions 
-11.txt supports pairwise and n-pairwise because offerer/initiator  
sends a master key to the answerer/responder and the latter (always)  
sends its master key back.  For "meet-me" (e.g. 3-way) conferencing,  
n-pairwise is very convenient.  I don't think that rsa-r or RFC 3880  
support this.  rsa-r does not support n-pairwise.

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,

Ignjatic, et al.         Expires January 8, 2006               [Page 10]

Internet-Draft                 MIKEY-RSA-R                     July 2005

    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-ext-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 think rsa-r may need to also need to admit tesla  
source-authentication in the case where A goes to talk to B but B is a  
bridge to C and etc.  If B hands out a group key, which is what I think  
you intend to do, then how does A tell if B, C or D is talking.  It  
might be that A just talks to B, and B is the only entity trusted to  
package RFC 3550 CSRC payloads from C and/or D.

4. Finally, this is a bit convoluted, I think:
   "Consider that A wants to talk to B and C, but does not have B's or
    C's CERT.  A might contact B and request that B supply a key for a
    3-way call.  Now if B knows C's CERT, then B can simply use the
    MIKEY-RSA mode (as defined in RFC 3830) to send the TGK to C. If not,
    then the solution is not straightforward.  For instance, A might ask
    C to contact B or itself to get the TGK, in effect initiating a 3-way
    exchange.  It should be noted that 3-way calling is typically
    implemented using a bridge, in which case there are no issues (it
    looks like 3 point-to-point sessions, where one end of each session
    is a bridge mixing the traffic into a single stream)."

I would forget about this.  I think you're defining a mode for a bridge  
to let it use a group key,  but I'm not sure what your trying to do  
here.

5. In summary, the group key may need better management than rsa-r is  
currently offering.  Here are three suggestions.
   (i)   I think the DH and PFS should be used
   (ii)  SRTP-TESLA may be used
   (iii) self-signed certs should not be used without SRTP-TESLA

cheers, Mark

On Jul 9, 2005, at 7:15 AM, Cullen Jennings wrote:

>
> I just noticed a new ID
>
> http://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt
>
> This one looks like it actually addresses most my issues with Mikey -  
> I have
> not thought about it too much yet but it looks much better than the  
> other 4
> modes. It still seems to have the artifact that the responder is  
> forced to
> choose the SRTP keys for both sides.
>
> The point that we are now up to 5 modes is interesting. Mikey is  
> starting to
> remind me very much of IKE.
>
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 11 Jul 2005 13:34:31 -0400

Hi Mark,

Thanks for your review.  I prepared a response on Saturday, and my 
mailer ate it :-).  So, here are my thoughts:

Mark Baugher wrote:

> hi
>   Thanks for posting draft-ietf-msec-mikey-rsa-r-00.txt.  I have a 
> few  comments.
>
>   I believe that msec key distribution typically RFCs use DH as part 
> of  group key distribution viz. http://www.ietf.org/rfc/rfc4046.txt.  
> So  this last sentence is wrong.

Our intent is to say that MIKEY-DH and DHHMAC, as specified in 3830 and 
the DHHMAC I-D, specify that group key distribution is unsupported.

So, if the issue is whether group DH schemes exist in the research 
literature, sure they do.  But, that is not what we are considering.  
The last sentence could use a rewrite say along the lines of: "these 
modes do not support group key distribution, as specified."

>    I think you're absolutely right but I would add a little bit 
> here.   MIKEY modes are today pairwise and your I-D adds a mode to 
> make it  possible for a bridge, mixer, mcu, server, or other type of 
> controller  to hand the end-system a group key.  Did I get that 
> right?  I think  it's true that MIKEY (RFC 3880) supports a pairwise 
> crypto context and  mikey-rsa-r supports a group crypto context.  
> That's fine, but what  about an n-parwise crypto context?  As a 
> footnote, I would add that  

MIKEY modes are run pairwise, but can be used to establish a group key.  
Section 8 discusses group key establishment with MIKEY (MIKEY-PSK and 
MIKEY-RSA modes support this).

Section 8 also says that the sender is the Initiator and contacts all 
authorized members and supplies the same key, CSB_ID and so forth.  
RSA-R facilitates the reverse operation which, I think, is attractive, 
if not preferable (somewhat similar to MSEC protocols).  Each member can 
request the sender or a center to supply keys (presumably after seeing 
an announcement for a conference).  There might be some issues as to 
whether the signaling support is sufficient (we will get to that latter).

I think I understand what is n-pairwise, but would like to be absolutely 
sure, so please define it for me pleas, so we can discuss that further.

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

We will definitely tighten up the language there and will also update 
the security considerations so that each end-point has guarantees as to 
who they are communicating to. 

We will make a note about SSRC collisions and address them in the next 
version.

> source-authentication in the case where A goes to talk to B but B is 
> a  bridge to C and etc.  If B hands out a group key, which is what I 
> think  you intend to do, then how does A tell if B, C or D is 
> talking.  It  might be that A just talks to B, and B is the only 
> entity trusted to  package RFC 3550 CSRC payloads from C and/or D.

We will talk about the need for source authentication in general, 
although I think for this document, that discussion will have a place 
only in the security considerations section.

> I would forget about this.  I think you're defining a mode for a 
> bridge  to let it use a group key,  but I'm not sure what your trying 
> to do  here.

We were trying to be comprehensive and say that in some cases -- the 
above example, which needs to be revised considering that it is 
confusing -- MIKEY-RSA-R mode might *not* be the best choice.  We don't 
have to write that in, but admitting in advance the limitations of the 
proposed mode.

>   (iii) self-signed certs should not be used without SRTP-TESLA

Unfortunately, I don't see the need for PFS (please make a case as to 
why that is necessary).  Furthermore, I think the DH modes should stay 
optional as they are now.

We'll include notes on source authentication.  I don't quite understand 
(iii), please elaborate.  Thanks.

Some notes on Cullen's email below:

Yes, MIKEY modes are increasing and I am not too happy about that.  
OTOH, I am not too worried that we are on the path of IKE.  IKE's modes 
were too complicated and too distinct from each other, making that 
protocol hard to analyze and understand.  MIKEY is much simpler and so 
far ok.  That said, I have in the past talked about and would be ready 
for a discussion on 3830bis.  Knowing what we now know, how would we 
revise that spec to contain most if not all of the modes and extensions 
in one well-woven spec.

The other topic of some interest to me is each end supplying own key 
material.  Aside from the crypto advantages there are usage advantages.  
RSA-R being a 2-message mode can have each side supply own key material 
(as I wrote in the previous paragraph, I would consider adding that 
feature optionally to the Verification messages in PSK and RSA modes).  
There are also some downsides too in that each sender would have to 
supply key material to all the members (but that is also a feature in 
that each member actually knows who might decipher the RTP traffic it 
sends).

Thanks again for your comments.

thanks and regards,
Lakshminath

>> This one looks like it actually addresses most my issues with Mikey 
>> -  I have

---

From: Mark Baugher <[email-masked]>
Date: Mon, 11 Jul 2005 10:59:02 -0700

hi Lakshminath,

On Jul 11, 2005, at 10:34 AM, Lakshminath Dondeti wrote:

> Our intent is to say that MIKEY-DH and DHHMAC, as specified in 3830  
> and the DHHMAC I-D, specify that group key distribution is  
> unsupported.
>
> literature, sure they do.

GDOI and GSAKMP use DH.

> But, that is not what we are considering.  The last sentence could use  
> a rewrite say along the lines of: "these modes do not support group  
> key distribution, as specified."

I think you want to make it clear that you are referring to MIKEY's  
modes and mode-lets and not to group key management in general.
>> possible for a bridge, mixer, mcu, server, or other type of  
> MIKEY modes are run pairwise, but can be used to establish a group  
> key.  Section 8 discusses group key establishment with MIKEY  
> (MIKEY-PSK and MIKEY-RSA modes support this).
>
> if not preferable (somewhat similar to MSEC protocols).  Each member  
> can request the sender or a center to supply keys (presumably after  
> seeing an announcement for a conference).  There might be some issues  
> as to whether the signaling support is sufficient (we will get to that  
> latter).
>
> I think I understand what is n-pairwise, but would like to be  
> absolutely sure, so please define it for me pleas, so we can discuss  
> that further.

In a forking context with sdescriptions, the offerer sends its key to n  
answerers who send their keys to the offerer (but not to each other)

>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext 
>> -15.txt)  maybe in some contexts (3GPP?).  SIP calls fork and RFC  
>> 3830  implementations may not handle SSRC collisions well when a fork  
> the security considerations so that each end-point has guarantees as  
> to who they are communicating to.

Well, where does one define the tesla bindings?  I would think that it  
needs to be in a MIKEY document and this looks like the right one -  
it's about multicast.

> confusing -- MIKEY-RSA-R mode might *not* be the best choice.  We  
> don't have to write that in, but admitting in advance the limitations  
> of the proposed mode.

To be comprehensive, you need to discuss the configurations where each  
side contributes key material either (i) each side sends its own master  
key as done in sdescriptions, (ii) each side has a Diffie-Hellman  
half-secret and does a DH exchange, and (iii) each side has its own  
master key that they provide to the initiator (but not to other  
parties) as done in an n-pairwise connection - all are distinct from  
the group-key case.

> optional as they are now.

If the long-term private key is compromised then all communications  
that are established used PKE without a DH can be compromised.

Mark

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 11 Jul 2005 14:10:53 -0400

Hi Mark,

Thanks for the follow-up.  Please see inline:

Mark Baugher wrote:

>>> 1.  It's nicely written and clear.  The last sentence below, 
>>> however,   is not accurate:
>>>   I believe that msec key distribution typically RFCs use DH as 
>>> part  of  group key distribution viz. 
>>> http://www.ietf.org/rfc/rfc4046.txt.   So  this last sentence is wrong.
>>
>>
>> and the DHHMAC I-D, specify that group key distribution is  unsupported.
>>

Only for establishing the one-to-one secure channel, not to actually 
using the DH exchange to generate the group key.  My understanding is 
that the MIKEY-DH mode uses the DH-key to generate the SRTP key, and 
therefore, as defined, does not support group communication.

>
>> But, that is not what we are considering.  The last sentence could 
>> use  a rewrite say along the lines of: "these modes do not support 
>> group  key distribution, as specified."
>
>

Indeed.

>>> make it   possible for a bridge, mixer, mcu, server, or other type 
>>> of  controller  to hand the end-system a group key.  Did I get that  
>>> right?  I think  it's true that MIKEY (RFC 3880) supports a 
>>> pairwise  crypto context and  mikey-rsa-r supports a group crypto 
>>> context.   That's fine, but what  about an n-parwise crypto 
>>> context?  As a  footnote, I would add that   
>>> sends a master key to the answerer/responder and the latter 
>>> (always)   sends its master key back.  For "meet-me" (e.g. 3-way) 
>>> conferencing,   n-pairwise is very convenient.  I don't think that 
>>> rsa-r or RFC 3880   support this.  rsa-r does not support n-pairwise.
>>
>>
>> Section 8 also says that the sender is the Initiator and contacts 
>> all  authorized members and supplies the same key, CSB_ID and so 
>> forth.   RSA-R facilitates the reverse operation which, I think, is 
>> attractive,  if not preferable (somewhat similar to MSEC protocols).  
>> Each member  can request the sender or a center to supply keys 
>> (presumably after  seeing an announcement for a conference).  There 
>> might be some issues  as to whether the signaling support is 
>> sufficient (we will get to that  latter).
>>
> In a forking context with sdescriptions, the offerer sends its key to 
> n  answerers who send their keys to the offerer (but not to each other)
>
Ok.  Actually, I didn't know that definition.  I will reread the emails 
with that information in mind and respond separately, if I could

>>> the  following security consideration is really important for 
>>> group   communications:
>>> 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   
>>> 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.
>>
>>
>> We will definitely tighten up the language there and will also 
>> update  the security considerations so that each end-point has 
>> guarantees as  to who they are communicating to.
>> We will make a note about SSRC collisions and address them in the 
>> next  version.
>>
>>>
>>> source-authentication in the case where A goes to talk to B but B 
>>> is  a  bridge to C and etc.  If B hands out a group key, which is 
>>> what I  think  you intend to do, then how does A tell if B, C or D 
>>> is  talking.  It  might be that A just talks to B, and B is the 
>>> only  entity trusted to  package RFC 3550 CSRC payloads from C 
>>> and/or D.
>>
>>
>> although I think for this document, that discussion will have a 
>> place  only in the security considerations section.
>
>
> Well, where does one define the tesla bindings?  I would think that 
> it  needs to be in a MIKEY document and this looks like the right one 
> -  it's about multicast.

:-).  3830 does give prominence to unicast communication, with brief 
notes about multicast and groups.  In any event, we will talk about the 
need for source authentication.

>>> bridge  to let it use a group key,  but I'm not sure what your 
>>> trying  to do  here.
>>
>>
>> don't have to write that in, but admitting in advance the 
>> limitations  of the proposed mode.
>
>
> To be comprehensive, you need to discuss the configurations where 
> each  side contributes key material either (i) each side sends its own 
> master  key as done in sdescriptions, (ii) each side has a 
> Diffie-Hellman  half-secret and does a DH exchange, and (iii) each 
> side has its own  master key that they provide to the initiator (but 
> not to other  parties) as done in an n-pairwise connection - all are 
> distinct from  the group-key case.
>
>>
>>>
>>> 5. In summary, the group key may need better management than rsa-r 
>>> is   currently offering.  Here are three suggestions.
>> Unfortunately, I don't see the need for PFS (please make a case as 
>> to  why that is necessary).  Furthermore, I think the DH modes should 
>> stay  optional as they are now.
>
>

But DH does come at a cost, i.e., p2p key generation, and MIKEY-RSA mode 
has a way to bootstrap the PSK mode.  Given those two facts, I still 
don't see the *need* for PFS.  The DH mode is an option and can be used 
if PFS is a requirement.

I will follow-up on any remaining topics in the next day or two.  Also, 
if you are coming to Paris, let us meet some time and discuss this 
further f2f.

thanks and regards,
Lakshminath

---

From: Mark Baugher <[email-masked]>
Date: Mon, 11 Jul 2005 11:20:06 -0700

One more comment...

On Jul 11, 2005, at 11:10 AM, Lakshminath Dondeti wrote:

...
> notes about multicast and groups.  In any event, we will talk about 
> the need for source authentication.

I think you should do more and define how it gets signaled.

Mark
>> each  side contributes key material either (i) each side sends its 
>> own master  key as done in sdescriptions, (ii) each side has a 
>>> to  why that is necessary).  Furthermore, I think the DH modes 
>>> should stay  optional as they are now.
>>
>>
> But DH does come at a cost, i.e., p2p key generation, and MIKEY-RSA 
> mode has a way to bootstrap the PSK mode.  Given those two facts, I 
> still don't see the *need* for PFS.  The DH mode is an option and can 
> be used if PFS is a requirement.
>
> I will follow-up on any remaining topics in the next day or two.  
> Also, if you are coming to Paris, let us meet some time and discuss 
> this further f2f.
>
> thanks and regards,
> Lakshminath
>
>>
>> Mark
>>
>>>
>>
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 11 Jul 2005 14:37:50 -0400

I am inclined to say, sure.  However, the bootstrapping-TESLA I-D 
defines how to.  Do you think the RSA-R document should repeat what's in 
bootstrapping-TESLA?  If you are for merging the various MIKEY drafts, 
as I noted, I am willing to open that discussion :-).

thanks Mark,
Lakshminath

Mark Baugher wrote:

>>> it  needs to be in a MIKEY document and this looks like the right 
>>> one -  it's about multicast.
>>
>>
>>>> We were trying to be comprehensive and say that in some cases -- 
>>>> the  above example, which needs to be revised considering that it 
>>>> is  confusing -- MIKEY-RSA-R mode might *not* be the best choice.  
>>>> We  don't have to write that in, but admitting in advance the

---

From: Mark Baugher <[email-masked]>
Date: Mon, 11 Jul 2005 11:56:48 -0700

On Jul 11, 2005, at 11:37 AM, Lakshminath Dondeti wrote:

> defines how to.

Yes, you're right.  I forgot about this document

Mark
> Do you think the RSA-R document should repeat what's in 
>>>> side has its own  master key that they provide to the initiator 
>>>> (but not to other  parties) as done in an n-pairwise connection - 
>>>> all are distinct from  the group-key case.
>>>>
>>>>>
>>>>>>
>>>>>> 5. In summary, the group key may need better management than 
>>>>>> rsa-r is   currently offering.  Here are three suggestions.
>>> still don't see the *need* for PFS.  The DH mode is an option and 
>>> can be used if PFS is a requirement.
>>>

---

From: Mark Baugher <[email-masked]>
Date: Wed, 13 Jul 2005 15:25:51 -0700

Francois, Lakshminath
    I think what we want to define for MIKEY is the ability of the 
responder to hand the initiator a key.  This is done in rsa-r and it is 
done in RFC 3547 (GDOI).  RFC 3830 (MIKEY) initiators hand the key to 
the responder, not vice versa, so I see why you want to change that 
when talking to bridges, controllers, etc.

>    Responder's identity; in other cases, a blacklist or a whitelist may

I don't see why we are going here and admitting antispam mechanisms in 
the key establishment.  I would expect that the initiator will 
establish a connection with the responder, which has a cryptographic 
identity.  What if the message gets redirected or (more likely) 
intercepted and another entity responds?  We discuss this in RFC 3547 
and also is RFC 4046:

"Alternatively, the sender may forward rekey messages on behalf of the
    GCKS when it uses a credential mechanism that supports delegation.
    Thus, it is possible for the sender, or other members, to source
    keying material (TPKs encrypted in the Group KEK) as it sources
    multicast or unicast data.  As mentioned above, the rekey message can
    be sent using unicast or multicast delivery.  Upon receipt of a TPK
    (as part of a Data SA) via a rekey message or a registration protocol
    exchange, the member's group key management functional block will
    provide the new or updated security association (SA) to the data
    security protocol.  This protects the data sent from sender to
    receiver."

In other words, rsa-r can be used by a credentialing mechanism that 
supports delegation or some other method that allows the initiator to 
determine (1) that the responder is authorized to respond (perhaps for 
an entity with a different identity) and (2) the initiator is 
authorized to communicate with the particular responder, or delegated 
responder.

The way it's written now, it just sounds like something that could be 
done very insecurely.  It says that the initiator is responsible but 
does not give a clue how it could be done.

Mark