Subject: [MSEC] Some comments to mikey applicability draft

From: "Vesa Lehtovirta \(JO/LMF\)" <[email-masked]>
Date: Mon, 6 Nov 2006 18:41:38 +0100

Hi,
 
Here are some comments to the MIKEY applicability draft.  Unfortunately
I have not been able to review all parts of the document with the same
depth.
 
- In generel I see that this kind of document is very useful, also in
the context of RTPSEC.  
- The structure of the document seems good, but I would like to propose
that section 3 could more clearly highlight/separate which modes of
MIKEY are original from RFC 3830 and which are introduced later.  
- The RCC draft mentioned in section 4.4 is not actually a MIKEY
extension, but an extension to SRTP. It is true that it introduces some
new parameters to be carried in MIKEY, but it is not a MIKEY extension
in the same sense as the other extension mentioned in section 4, so it
could probably even be left out or re-categorized . 
- The scope of the document could be clarified somewhat. The abstract
gives the impression that it is giving overview of MIKEY and extensions,
but introduction says that it gives also insight to different use cases.
These could  be aligned and the introduction could probably also shortly
discuss what kind of use scenarios are going to be analysed (especially
the use cases described in section 5  could be mentioned). 
- The section 7 on MIKEY related IANA registrations could be closer to
section 10. 
 
- In introduction, the key distribution methods could include a
reference to the applicable RFC or draft
- In the paragraph just above 3.1 it is said: 

 " Neverheless in multimedia communication scenarios

   supporting forking Section 5.2, collisions may occur leading to so-

   called two-time pads, i.e., the same key is used for media streams to

   different destinations. " 

Comment: It should be noted that two-time pads can also happen to
streams going to the same destinations. Actually the risk is there if
there is a possibility of collision of all parameters that are used for
keystream calculation. 

- In 6 on transport of MiKEY messages it could be added that MIKEY can
also be transported over plain UDP and then the port number is 2269.
 
best regards,
  Vesa
 
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 6 Nov 2006 19:18:38 +0100

Hi Vesa,
 
thanks for the commenst on the applicability draft. I'm preparing an
updated version of the draft and will include your comments. 
 
Regarding RCC, well, its not rally an extension, but as it defines some
new payloads, we thought for the sake of completness we state it as
well. I will make a note regarding the MIKEY relation in out draft.
 
Regards
  Steffen

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Vesa Lehtovirta
(JO/LMF)
	Sent: Monday, November 06, 2006 6:42 PM
	To: [email-masked]
	Subject: [MSEC] Some comments to mikey applicability draft

	Hi,
	 
	Here are some comments to the MIKEY applicability draft.
Unfortunately I have not been able to review all parts of the document
with the same depth.
	 
	- In generel I see that this kind of document is very useful,
also in the context of RTPSEC.  
	- The structure of the document seems good, but I would like to
propose that section 3 could more clearly highlight/separate which modes
of MIKEY are original from RFC 3830 and which are introduced later.  
	- The RCC draft mentioned in section 4.4 is not actually a MIKEY
extension, but an extension to SRTP. It is true that it introduces some
new parameters to be carried in MIKEY, but it is not a MIKEY extension
in the same sense as the other extension mentioned in section 4, so it
could probably even be left out or re-categorized . 
	- The scope of the document could be clarified somewhat. The
abstract gives the impression that it is giving overview of MIKEY and
extensions, but introduction says that it gives also insight to
different use cases. These could  be aligned and the introduction could
probably also shortly discuss what kind of use scenarios are going to be
analysed (especially the use cases described in section 5  could be
mentioned). 
	- The section 7 on MIKEY related IANA registrations could be
closer to section 10. 

	   supporting forking Section 5.2, collisions may occur leading
to so-

	   called two-time pads, i.e., the same key is used for media
streams to

	Comment: It should be noted that two-time pads can also happen
to streams going to the same destinations. Actually the risk is there if
there is a possibility of collision of all parameters that are used for
keystream calculation. 

	- In 6 on transport of MiKEY messages it could be added that
MIKEY can also be transported over plain UDP and then the port number is
2269.
	 
	best regards,
	  Vesa