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

From: "Vesa Lehtovirta (JO/LMF)" <[email-masked]>
Date: Fri, 24 Feb 2006 10:25:03 +0100

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?

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

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

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

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

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. 

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

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