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

From: "Vesa Lehtovirta (JO/LMF)" <[email-masked]>
Date: Tue, 7 Mar 2006 14:06:34 +0100

Hi,
 
Thanks for your responses to my comments and sorry for my delayed
response. 
I have just two further comments:
 
- w.r.t. the clarification you are making to the Abstract about using
MIKEY also with other security protocols and not only with SRTP, I think
this may need to to be clarified also in some other places in the draft
where SRTP is mentioned. 
 
- the second comment:
>>- 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?

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

For my understanding, could you elaborate further, when is the same
keying material used and when different? 

Best regards,

  Vesa

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ignjatic, Dragan
	Sent: 4. maaliskuuta 2006 4:08
	To: Lakshminath Dondeti; Vesa Lehtovirta (JO/LMF);
[email-masked]
	Cc: [email-masked]
	Subject: RE: [MSEC] Comments to draft
draft-ietf-msec-mikey-rsa-r-02.txt

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

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

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

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

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

	[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

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 07 Mar 2006 11:24:49 -0800

At 05:06 AM 3/7/2006, Vesa Lehtovirta \(JO/LMF\) wrote:
>Hi,
>
>Thanks for your responses to my comments and sorry for my delayed response.
>- w.r.t. the clarification you are making to the Abstract about 
>using MIKEY also with other security protocols and not only with 
>SRTP, I think this may need to to be clarified also in some other 
>places in the draft where SRTP is mentioned.

I caught most if not all of them.  We submitted an -03- based on 
Steffen's and your reviews and the ensuing discussions.  Dragan and I 
went back and forth on allowing certain things and those influenced 
the MUST/SHOULDs a bit more, but we clarified all of that with 
follow-up explanatory text.  Please look at the diffs when the I-D 
shows up in the repository.  More in line.

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

So there is a case for one side to pick all the parameters especially 
SSRC and RAND to avoid collisions (e.g., MIKEY-RSA and MIKEY-PSK with 
the 1 message case already allow this model).  We are just trying to 
keep all the features intact, especially to allow collision-free 
operation in group communication (note: it is of course possible to 
continue to use RTP's random SSRC selection algm).

regards,
Lakshminath

>----------
>To: Lakshminath Dondeti; Vesa Lehtovirta (JO/LMF); [email-masked]
>Cc: [email-masked]
>Subject: RE: [MSEC] Comments to draft draft-ietf-msec-mikey-rsa-r-02.txt
>
>Hi Vesa,
>Many thanks for the review. I tried to clarify some of Lakshminath's points.
>
>Best regards,
>Dragan
>
>
>----------
>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,
>
>response.  Dragan and I were I guess hoping the other would respond
> >In general the draft is well written and an interesting approach.
> >
> >Best regards,
> >
> >    Vesa
> >
> >several modes of key distribution to setup Secure Real-time Rransport
> >Comment: The draft generally gives the impression that MIKEY is used
> >specified already for SRTP in MIKEY RFC3830. MIKEY is extensible to
> >be used with other security protocols also but this may require that
> >possible security protocol and not the only possible one. Or is it
>I appreciate the distinction you are making.  We'll address this by
> >- 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
> >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?
>
>Initiator knows the specific Responder's ID it wants to communicate
>with and specifies it, what happens if due to forking or redirect or
>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 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."
>
>[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.
>
> >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?
> >
> >"The authors believe that multiple TGK payloads can be used for this
>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"?
>
> >- 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
> >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) -->
> >
>Thanks Vesa for a very thoughtful and thorough review.  We'll address
>[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