Subject: Re: [MSEC] Comments to draft draft-ietf-msec-mikey-rsa-r-02.txt

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 03 Mar 2006 01:36:03 -0800

Hi Vesa,

Many thanks for your comments.  I apologize for the delay in my 
response.  Dragan and I were I guess hoping the other would respond 
and he noted he will be commenting tomorrow.

I will try to address your comments below:

At 01:25 AM 2/24/2006, Vesa Lehtovirta \(JO/LMF\) wrote:

>Hi all,
>
>Here are some comments, and also questions, to the 
>draft-ietf-msec-mikey-rsa-r-02.txt.
>
>In general the draft is well written and an interesting approach.
>
>Best regards,
>
>    Vesa
>
>- Issue: Abstract says that
>"The Multimedia Internet Keying (MIKEY) specification describes
>several modes of key distribution to setup Secure Real-time Rransport
>Protocol (SRTP) sessions..."
>
>Comment: The draft generally gives the impression that MIKEY is used 
>solely for setting up keys for SRTP. However, MIKEY is not 
>restricted to SRTP only, although certain parameters have been 
>specified already for SRTP in MIKEY RFC3830. MIKEY is extensible to 
>be used with other security protocols also but this may require that 
>needed parameters can be specified also for other security 
>protocols. Therefore, it would be good to mention SRTP as one 
>possible security protocol and not the only possible one. Or is it 
>the intention that this would be used only with SRTP?

I appreciate the distinction you are making.  We'll address this by 
rewording that paragraph.

>- Issue: One of the main points in the draft is that the Initiator 
>may not know the Responder's ID and in 3.2 it is said for the I_MESSAGE:
>
>"If the Responder has multiple Identities, the Initiator MAY also
>include the specific ID, IDr, of the Responder that it wants to
>communicate with."
>
>Comment: The question is, if the IDr is not indicated in the 
>I_MESSAGE, how can the message be routed to the correct responder? 
>If this is assumed to be done in some other layer, e.g. SIP, how can 
>the initiator know the SIP layer identity if it does not know the 
>MIKEY layer identity? Or is it assumed then that e.g. the SIP layer 
>identity may be known even though the MIKEY layer identity is not known?

Yes.  But, I guess that MAY can be clarified further.  If the 
Initiator knows the specific Responder's ID it wants to communicate 
with and specifies it, what happens if due to forking or redirect or 
something it goes to a different place.

W.r.t. routing the message though, my understanding is that's all SIP 
level and not up to MIKEY.  We can only specify how MIKEY messages 
are to be processed if and when they go to an unintended entity.

>- Issue: In 3.2 it is said that "The Initiator MAY indicate the 
>number of CSs supported,.." but in 3.2 it is said that "The 
>Responder MUST fill in the number of CSs"
>Comment: Why is it differently? Should both be MUST?

I think this is ok.  If the Responder is a sending to a group (or a 
group key server), then the Initiator does not need to fill in the CS 
information.  In either case, it is ok to have the Responder fill in 
the information.

Are you suggesting that for the unicast case, the MAY ought to be a SHOULD?

>- Issue: In 5 (last para) it is said that "Unicast and multicast 
>keys have different
>security properties and should not be derived from the same pool."

Ok, that's vague.  We'll clarify further.

>Comment: Usually we can trust to one-way key derivation functions to 
>provide key separation. Is there a reason why we cannot assume it here?
>
>- Issue: In 5 (last para) it is said that
>"The authors believe that multiple TGK payloads can be used for this
>purpose but the exact method is not specified in MIKEY."

Right, we talked a lot about this and we thought it is under 
specified or something, but decided that it is out of scope for 
RSA-R.  But that statement might best be removed or further clarified.

>Comment: When checking this seems to be specified in 6.2 and 6.13 of 
>RFC 3830.
>
>- Smaller stuff: In 3.3 (page 7): What is "complete CS map"? Is it 
>"CS ID map info"?

We'll rewrite that.  Thanks for catching this.

>- Smaller stuff: In 3.4.1, 3.4.2 and 3.4.3 it could be indicated 
>what is new information.

Will do.

>- Finally some comments on some "extra" messages on the proposed 
>procedure: The current draft proposes a solution where the Initiator 
>prompts the Responder to send the TGK key. I wonder if the procedure 
>could be extended with a Verification message to know that the key 
>has been delivered (as in current MIKEY):
>
>Init             Resp
>-----            ----
>I_MSG[CERTi]  -->
>        <-- R_MSG(TGK)[CERTr]
>I_MSG[Verif] -->
>
>Also, the current draft does not allow the Initiator to choose the 
>TGK. I wonder if the procedure could be also extended with a new 
>message in the beginning of the procedure where the Init could ask 
>the Resp to request the key from Init. I guess you have thought of 
>this since this case has been shortly discussed in 4.1 but then you 
>have abandobed it as too complex?: "For instance, A might ask C to 
>contact B or itself to get the TGK, in effect initiating a 3-way exchange. "
>
>Init             Resp
>-----            ----
>I_MSG[CERTi] -->
>        <-- R_MSG[CERTr]
>I_MSG(TGK) -->
>
That would be a 3-way exchange and my take is no.  :-).

Thanks Vesa for a very thoughtful and thorough review.  We'll address 
your comments in the next rev.

best regards,
Lakshminath 

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

---

From: "Ignjatic, Dragan" <[email-masked]>
Date: Fri, 3 Mar 2006 18:08:11 -0800

Hi Vesa,
Many thanks for the review. I tried to clarify some of Lakshminath's points.
 
Best regards,
Dragan

________________________________

From: Lakshminath Dondeti [mailto:[email-masked]]
Sent: Fri 3/3/2006 1:36 AM
To: Vesa Lehtovirta (JO/LMF); Ignjatic, Dragan; [email-masked]
Cc: [email-masked]
Subject: Re: [MSEC] Comments to draft draft-ietf-msec-mikey-rsa-r-02.txt

Hi Vesa,

[D.I.]: This depends on whether we want to allow multiple different (unicast/multicast) streams to use the same keying material. 

[D.I.]: We will clarify in the draft. This only means that the same keying material should not be used for both multicast and unicast streams as it may introduce two time pad problems with multiple unicast sources that pick their own SSRC's.

[D.I.]: I believe what is lacking is a good mapping mechanism between TGKs and sessions and again decided RSA-R is not the way to introduce it.

Will do.

[D.I.]: Right, even if the three way handshake can be justified I don't think RSA-R work should introduce it.

best regards,
Lakshminath