Subject: [MSEC] comments on draft-ietf-msec-mikey-01.txt

From: Mark Baugher <[email-masked]>
Date: Mon, 01 Apr 2002 18:17:54 -0800

I read the draft and have a number of comments.  This looks like a complete 
draft. Glad to see that.  I'll try to give a complete review.

S 1.2: Why use "pre-master key" when there is no master key or post-master 
key used in the draft?  The problem is that you tend to slip into using 
"master" to refer to the PMK as in section 4.1.

S 2.1: You give four definitions for four scenarios but then introduce 
other types in the commentary:  You introduce "one-to-many (one-to-'a 
few')" in the commentary but define "simple one-to-many" in scenario d, and 
then introduce "small-size interactive groups."  This leaves me wondering 
what properties of the one-to-many are you addressing or not 
addressing?  Also, you don't state which of the many-to-many scenarios you 
support or don't support and why.

P 8, last para: What is mean't by "external" group re-key protocol.  Why 
does MIKEY need to use re-key at all?  I think that there is a 
media-on-demand (RTSP) scenario where it might be useful: If the media are 
pre-encrypted to off-load crypto operations from a media server, then 
pushing the session key protected by a KEK without registration might make 
a lot of sense rather than always requiring an authenticated key 
establishment.  This is not addressed in MIKEY.  If it were, it might be 
better done within the RTSP message rather than by some "external" 
protocol.  As it is, I don't see the need for re-key in this draft.

S 2.5: You tend to repeat that MIKEY is for real-time data, but I don't 
think the properties of the data-security protocol motivate the need for 
MIKEY as much as low-latency (one or two message) key establishment.  I 
think MIKEY's motivation is low-latency key establishment and not real-time 
or continuous time data.

S 3.0, 2nd para: "signing" should be "authentication"

S 3.0, last para: I had a problem with the fact that you left the header, 
parameters and policies out of the flows because I could not easily see 
where the various payloads were used.  The table in Appendix B is hard to 
use in my opinion.

S 3.1 after Figure 3.1: "Authentication of the peers..." should be 
"Authentication of the message..."  Also, shouldn't the initiator have a 
means to request that the responder send a verification message?

S 3.2, fig 3.2: It appears that IDa is always sent and is encrypted whereas 
I is set to IDa or cert_a; do you mean to encipher I and not IDa?

S 3.3: You state why DH might not be used but not why someone might choose 
to use it:  PFS.

P.13, 4th para from bottom: The signature covers the Initiator's Id:  This 
is the I value that is either the ID or the cert, right?

S 4.1, second bullet: Fig 3.2 derives a KEK from Rand so I am confused 
about the use of the DH values for deriving the KEK - it seemed like a KEK 
is derived only when DH is used.

S 4.1.3: I found use of "inkey" to be confusing.  It's the same as "s" 
where you introduce the notation to be used in 4.1.2, isn't it?

S 4.1.4: The first note does not make sense.  The second note should be "or 
the one" rather than "and the once."  Is the source of the decimal digits 
arbitrary?

S 4.2: I did not find any guidance for how new transforms are added to 
MIKEY.  Also, if you have mandatory transforms, I don't see what the 
interoperability problems are that you caution against in this paragraph.

S 4.2.3, note: :-)

S 4.2.4:  I got confused about the fact that MIKEY provides a framework 
where the transforms are upgradeable and replaceable; perhaps a separate 
section that lists the mandatory and default algorithms; perhaps more 
generality in the rest of the draft would help.

S 4.4: It is not clear what your model is wrt the data security 
protocol.  Does the latter maintain the SAs?  This is what I would 
expect.  It seems that MIKEY maintains the SAs since you have a MIKEY SA 
database.  What is not clear to me is MIKEY's SAs (that would include the 
cached keys used for MIKEY key download) and the data security protocol 
(e.g. SRTP) SAs, which I expect the data security protocol will 
maintain.  These are two different things.  The IKE model is that the 
security protocol SA gets handed over to the security protocol and that is 
the end of the matter.  Why not adopt this model?  Also, 4.4 is very 
specific to one security protocol, SRTP.  It might not be bad to support 
just SRTP, but other parts of the draft indicate that you want to support 
other protocols.  If so, you need to generalize the mechanisms beyond SSRCs.

S 4.5:  Again, need for re-key in the gkmarch sense is not clear to me.  It 
also is not clear to me who initiates MCS updating and how one end can 
recognize what the other end has or has not cached.

S 5.2, fig 5.1: "Figure 5.1: MIKEY payload example" - "payload" should be 
"message."  In the last bullet, "master payload" is mentioned but I don't 
know what this is.

S 5.3: I would like to see flows that list the mandatory and optional 
payloads for each message in some order that might be optimal or at least 
as good as any order.  It seems that every payload besides the header 
"payload" can be put in an arbitrary order and it's not clear until the 
very last page what payloads go with what messages.  I find this hard to 
understand and evaluate.  Also, in the third to the last bullet, why say 
the message "SHOULD" be processed if authentication is successful; 
otherwise, why begin processing the message at all?  I don't see why in the 
second to the last bullet that an authentication failure is a MUST report 
and a protocol failure is a SHOULD report.  Finally, the last bullet starts 
with "if needed" but does not give the conditions when such a thing is needed.

S 5.4: Replay handling is very confusing to me and this section did not 
shed much light on it for me.  Since signatures are used, the costs of 
getting this wrong are quite high.  What are the scenarios for protecting 
against DoS?  Are they different for attacks against RTSP servers? SIP 
initiators?  SIP responders?  What is the needed clock synchronization (I 
seem to recall some text about 5 minutes (!?) but it's apparently not in 
this section).  I think we need a model to describe the interaction of 
replay attacks with various degrees of clock synch?  How does this change 
when the particular entity is under attack?  Do we need to worry about proxies?

S 5.5: "transporting protocol" is a bit confusing I think because SDP in 
SIP or RTSP is a transporting protocol.  I think you mean "on an unreliable 
transport" as distinct from SIP or some other protocol that carry's the 
MIKEY and ensures reliability

S 6.1:  A complete example would be reassuring.  In fact, is there to be a 
reference implementation available sometime soon?

S 6.2, 3rd para from end: "MIKEY must signal to SIP" is a bit sloppy since 
SIP is a protocol specification.  I think you mean the SIP 
implementation.  It would be better I suspect if we linked the protocols by 
mapping MIKEY error codes and result codes to SIP error/result codes.  In 
this way, we might ensure that MIKEY failure definitely maps into SIP 
failure without the need to specify implementation behavior, i.e. we handle 
the linkage at the protocol level.

S 6.3, last para: Would it make sense to select ANNOUNCE or SET_PARAMETER 
as the operation that tunnels the MIKEY message and say that these are 
mandatory to implement when MIKEY is used?  It's clear that some changes 
are needed to the SIP or RTSP implementations (preceding note).

S 6.4, first bullet: One interface option is to use the SA DB and API where 
the security protocol (SRTP) signals MIKEY through an application interface 
that results in updates to an update to SRTPs crypto context (SADB) by MIKEY.

S 6.4, second bullet: This interface might be the mapping between MIKEY 
result codes and SIP or RTSP codes so the desired behavior of the host 
protocol (SIP, RTSP) is unambiguously defined.

S 6.4, last bullet: Is there any need or possibility for carrying a MIKEY 
"de-registration" or "tear-down" message?  such a message could explicitly 
request state be de-allocated or request that some state be maintained if 
that's needed.

S 7.1: This application does not seem very compelling to me.  More likely 
is the VOD scenario or large (not small) broadcast examples where the 
server does not perform any crypto because that reduces server capacity for 
pumping out data or the server should not have the keys to the content 
(that is pre-encrypted).  Also, the last sentence states that "security 
considerations...MUST be considered" but does not say exactly what they 
are.  If they are security considerations from some other spec, I don't 
think that's MIKEYs business - the implementers need to comply with the 
other spec.

S 7.2: Why can't DH be used and why can't multicast be used?

S 8.1, 1st para: You don't state what size should be used but instead tell 
us what sizes are not appropriate.  The I-D is unambiguous regarding the 
hash function in paragraph 3.

S 8.2: I don't understand how it can be MIKEY's business to add MUSTs to 
specs that are already written.  MIKEY is there to establish keys for 
security protocols and can give guidance on key usage.  But if the spec for 
the data security protocol is broken, I don't see how you can mandate 
through MIKEY that it be fixed.

S 8.3:  Here is the 5-10 minutes point I mentioned above.  Where does this 
come from?  What is a "client?"  What is a "very high load" of incoming 
calls?  I think we need more of a model to understand the underlying process.

S 8.6: I don't understand why this applies only to groups.

S A: I don't think that this should be relegated to an appendix since the 
point of the spec is to define how to develop interoperable 
implementations.  I'd move this into the body of the document.

S A.1, next payload bullet: Is it admissible to have the header payload 
with no other payloads following it?

S A.1, #CS: Are there a maximum 256 CSs or 255?  How do you interpret 0?

S A.1, CS ID map type:  Why is this mandatory?  Are you saying that if 
MIKEY is used to support some other data security protocol other than SRTP, 
then SRTP must there anyway?  I think that mandatory-to-implement ensures 
interoperability, but requiring support for SRTP does not ensure MIKEY 
interoperability at all.

S A.1.1:  Why do we start at bit 16 rather than bit 0? Regarding Policy nr 
and SSRC x, does this correspond with #CS above.  If so, is there a zero 
case corresponding to a #CS of zero?  I assume that the src/dst addresses 
are coming from some other place than this payload.  Also under the SSRC x 
bullet, I think that some point needs to be made about ensuring uniqueness 
and avoiding collisions.

S A.2, 1st para:  I had to search to find that "last payload" is defined in 
the table in A.1.

S A.2, 3rd para:  A graphic representation as done in IKE would be easier 
to follow.  For example, you say that something MUST be added to the 
encrypted data but don't state the order.  But you do give some idea of the 
ordering in fig 3.2.  But fig 3.2 is more informative than normative since 
it is not a complete spec, merely expository.  Again, I think I'd like to 
see the complete payload orderings given as in figures 3.

S A.2, encr data bullet: What about KEKs? (though I think you should 
consider dropping re-key and then won't need to worry about KEKs).

S A.4, DH key length bullet: Isn't this fully specified by DH-group?

S A.4, KV bullet:  You could adopt the new SRTP terminology of MKI.  But if 
you want to support security protocols other than SRTP, then a generic name 
such as "SPI" might be more suitable.

S A.5, 1st para: A graphical depiction of the payload flows as in figures 3 
would help identify where this sig payload goes since you define a "last 
payload" value and state in the other payloads when to set the next payload 
to the "last payload" value but here you say that the sig payload is the 
last payload for certain messages.  So I'm confused as to when the next 
payload is set to last payload (value 0) or to sig (value 4).

S A.5:  Where is the signature type declared?  It seems that other payloads 
are self-announcing (e.g. the ID/cert payload), but this one is not.

S A.6, next payload: so I assume that only in the pre-shared key case are 
we concerned with setting next payload to "last payload" (value 0) since in 
the other cases it would be set to the sig payload.

S A.9: Is this only for the pre-shared key establishment procedure?

S A.10.1, payload: Hmm, here's another that starts at bit 16.  We should 
add an SRTCP encryption bit to signal the member to encrypt or not encrypt 
the SRTCP.

S A.10.1, encr alg, auth alg: There are two notions of mandatory 
here.  first is mandatory when SRTP is supported and the second is 
mandatory-to-implement for MIKEY.  As I stated above, I think that nothing 
related to SRTP should be mandatory-to-implement for MIKEY.

S A.10.1:  for this item and maybe for some others, you may want to use 
type/length/value syntax rather than forcing everything to be 
specified.  If you used TLVs, then it would be possible to let the 
encryption algorithm and key length default while specifying a non-default 
SRTP authentication algorithm or tag length.  Also, TLVs are more 
extensible when you want to support other security protocols.  It's not 
clear how you let some things default while overriding others.

S A.10.2:  do we really want to separate the SRTP from the SRTCP 
policy?  This seems to be an unnecessary complication to me.

S A.10.3:  I think you should consider dropping re-key altogether.

S A.13:  When there are optional fields, I think that TLV syntax may be 
more appropriate.

S A.13, KV bullet:  I recall that you earlier stated that a lifetime is a 
MUST but there is a NULL option of no specific lifetime.  Do you mean that 
Null indicates that the security protocol default is to be used.  Also, the 
key validity period applies to the master key (PMK) in SRTP and not to a 
session key (TEK), right?

S B:  I find the tabular method of specifying message payload syntax to be 
hard to parse, maybe that's just because I'm accustomed to the more 
graphical representation of describing each message associated with an 
arrow (viz. figures 3) by listing the mandatory and optional payloads that 
compose the message.

cheers, Mark

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

---

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Tue, 2 Apr 2002 10:41:32 +0200

Thanks Mark,

Indeed, it seems to be a complete review (many thanks!). 
I will not try to answer all comments and questions 
(instead I will try to do that by considering them 
when I'm updating the draft). If there are any comments 
that you would like a quick answer on, just drop me 
another mail, and I'll try to do that. However, I have 
provided a few answers/comments on a few selected items 
(see below). 

> "master" to refer to the PMK as in section 4.1.

The notation PMK is something that was used in the first version 
of the draft (when we still used the notation master key instead 
of TEK). So I think it might be time to change PMK to something 
else (e.g. master key). 

> where you introduce the notation to be used in 4.1.2, isn't it?

No. inkey = s_1 || ... || s_n  (i.e. the inkey is split into n 
512-bit blocks, and each block, s_x, is fed into P(s_x, seed, m) )

> reference implementation available sometime soon?

We will (hopefully) start this week to update the current 
implementation so that it conforms to the current draft. 

> are needed to the SIP or RTSP implementations (preceding note).

Very good point. I was recommended at the meeting to do this by some 
RTSP people (i.e. the ANNOUNCE will be the mandatory). 

> request state be de-allocated or request that some state be 

Could be... But as long as SIP and RTSP is used, a kind of 
teardown will be done when the SIP/RTSP session is closed 
down. However, it may still be a good idea to include it 
to make it possible to have an explicit teardown. 

> S 7.2: Why can't DH be used and why can't multicast be used?

Multicast can very well be used (that was more or less assumed, 
but unfortunately not explicitly stated). However, using a DH exchange 
will not make it possible to create the same TEK to two (or more) 
participant (this is because the TEK is generated from the DH-key).
Therefore, the DH is not suitable for group communication. 

> clear how you let some things default while overriding others.

I agree, the TLV approach is probably better to use. 
 
> S A.10.3:  I think you should consider dropping re-key altogether.

Done. I brought the re-key stuff in to be "more" compliant to the 
GKMARCH, and to see if someone saw a need for it. If someone would 
see a need for it in the future, it would be possible to extend 
MIKEY with that. But so far, I have not seen any indications of the 
need for it (and both your and Martin's comments indicates that it 
may be worth to remove). 

We will continue to update the draft with more (and hopefully 
understandable) explanations. I think your review together 
with Martin's review have given us a quite good view of where to 
add more explanations. 
 
Thanks,
Fredrik