List Info

Thread: Some comments to mikey applicability draft
Some comments to mikey applicability draft
user name
 2006-11-06 17:41:38 

  


  

    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


 

  

  
  
   
     
    

  

    Some comments to mikey applicability
draft
  


  

     user name

     2006-11-06 18:18:38
  


  

    

  


  

    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: msec-bouncessecuremulticast.org 
  [mailto:msec-bouncessecuremulticast.org] On Behalf Of Vesa Lehtovirta 
  (JO/LMF)
Sent: Monday, November 06, 2006 6:42 PM
To: 
  msecsecuremulticast.org
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. 

  
 

  
- 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

  
 

  

  
  
   
     
    






 [1-2]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )