Subject: [MSEC] MIKEY-03 - some feedback

From: Euchner Martin ICN M SR 3 <[email-masked]>
Date: Mon, 22 Jul 2002 12:43:03 +0200

Dear all,

I've to excuse that I'm late with my review feedback, but I was so busy with
other things around.

Several issues in the most recent draft called my attention, and I would
like to bring them to your consideration for comment and/or correction.

First of all: The new version looks much more clear than MIKEY-01; I really
appreciate that.

1.) Section 1.2 and security protocols in section 3.1, 3.2 and 3.3
denote {SP} as zero or more occurrences. However, when first reading the
draft straight through, it was long not clear what the purpose for empty SP
should be. Later in the document, it appears that the empty SP cares for TGK
re-keying (?) where SP and other static values be left out. Is this my
correct understanding?
My recommendation is to add some clarifying text on that in the chapter 3
with some forward pointer to section 4.5

2.) Section 2.1 Scenarios
Case c) depicts many-to-many communication through a centralized conference
server. I do not understand why MIKEY could not be used for such scenario
(as stated in the very last sentence). I can imagine either one of the three
MIKEY key management protocol being applied between an end point and the
server S.

3.) Section 3
"RAND ... It is not included in update messages of a CSB. See Section 6.11
for payload definition."
I do not quite get it, why the update protocol remains secure when omitting
the RAND, but for the initial message the RAND is absolutely necessary?
Shouldn't there be a RAND in the update messages too, to protect against
off-line cryptanalysis attacks?

4.) Section 3.2 Public-key encryption
Regarding description of the PKE, I would love to see the related crypto
protocol be shown too; e.g.:
PKE = E(PK_R, env_key)

"If the Responder possess several public keys, the Initiator can use CHASH
to indicate the key used."
I do not get the idea here when I look at section 6.8 and recognize that
CHASH is just a hash of the certificate. Is thus CHASH an implicit
indicator? Should the receiver try through all certificates and cross-check
with the CHASH until a correct one is found?

Why not include the CertificateSerialNumber from the X.509 certificate as an
identifier of the public key?

"Note that there will be one encrypted IDr and possibly also one unencrypted
IDr. The encrypted one is needed to avoid certain man-in-the-middle attacks,
while the unencrypted is always useful for the Responder to immediately
identify the Initiator."
These two sentences made me confused and I'm not even clear if the I_message
or the R_message is meant. Further, the depicted protocols do not show the
possibility to have several IDs (plaintext and encrypted). I couldn't even
find a payload that holds an encrypted ID.
So what's missing here???

Please clarify.

5.) Section 4.1.5
This section shows a label for generating a salting key from the
pre-shared/envelope key. I do not quite understand if a salting key is
defined for a pre-shared key and what it should be good for. The same might
be true for the envelope key as well.
(I understand the concept of a salting key derived from a TGK, this could be
useful for SRTP for example).

6.) Section 4.3 "Policies", and also 6.10.1
I'm not yet convinced that the notion of "policy" in this MIKEY context is
fully appropriate. My understanding of a policy is something of a rule set
of general, more high-level behaviour of security systems whereas MIKEY uses
policy more in the view of bundled set of security parameters.
Thus, you should consider the term "security parameters" instead, which by
the way is abbreviated as SP too!

7.) Section 4.5 TGK re-keying
"... i.e. all parameters that are static or optional to include may be left
out."
I'm not certain if this statement if fully precise. For example what about
static and mandatory fields (like HDR)? It is probably more convenient to
shortly enumerate those fields and pieces that can be left out.

"New Crypto Sessions are added if desired in the update message. Therefore,
the new MIKEY message does not need to contain keys."
I don't get this completely. Which TGK or other key should a newly added
crypto session apply if the update does not convey a key?

Does this mean that TGK re-keying is a different procedure than CSB
updating?

8.) Figure 5.1
I'm just curious whether 32-bit alignment of the payloads is an
issue/requirement. My rough guess is that not all defined payloads start on
even 32-bit aligned locations.

9.) Section 5.5 Reliability
I recommend to add a fourth bullet "always send the verification message" as
a means to enhance the reliability.

10.)  Section 6.6 Timestamp payload
Not being an NTP expert, what is the reason to mandate both NTP formats?
What exactly refers the "NTP" TS type to?

11.)  Section 6.7 ID payload (ID)
My understanding is that this payload is able to convey either some identity
or to convey a digital certificate. By the manner how the values are
assigned to both categories and the fact that the values overlap, it is not
possible to distinguish both cases cleanly (0 could mean NAI or X.509v3)

12.)  section 6.12 Error Payload (ERR)
I observe that error code value 3 is used multiple times (invalid MAC,
invalid EA, invalid HA). Is this intentional to map all those cases to a
single number?

13.) Section 7.2 MIKEY within SIP
Wouldn't it be good practice to always include the V message when the
pre-shared method is applied? This nicely fits into the SIP offer/answer
model anyway and doesn't cause much effort for the responder to generate.

14.) Section 9.5 DoS
" For example, the SIP protocol can provide this using the anonymous
authentication challenge mechanism (specified in Section 22.1 of [SIP])."
This is true, but the downside of this technique is that is adds another
roundtrip to the exchange. I fear that this additional DoS countermeasure is
unavoidable if required.

With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 47713
| ICN M SR 3                     mailto:[email-masked]
|                                mailto:[email-masked]
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

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

---

From: "Fredrik Lindholm" <[email-masked]>
Date: Tue, 23 Jul 2002 11:13:05 +0200

Hi Martin,

thanks for the feedback, see comments inline.

>re-keying (?) where SP and other static values be left out. Is this my

Correct

>with some forward pointer to section 4.5

ok

>MIKEY key management protocol being applied between an end point and the

Yes this is true. By this we do not want to say that it will be impossible
to use
MIKEY in that particular scenario. However, it was not the main addressed
scenario when MIKEY was created. Maybe we should explain more the
aimed trust model that we have assumed are scenarios without the new
need of a common trusted party (which the central server would be).

>off-line cryptanalysis attacks?

No. I don't see that as necessary.

>with the CHASH until a correct one is found?

Yes, but "all certificates" are hopefully not that many, and I do expect
that you
already have the hashes of your certificates (if you posses more than one)
so that you can use the CHASH as a lookup for the certificate. Of course
in the X.509 case, the serial number could have been used for the same
functionality.

>identifier of the public key?

Then you tie it to a specific certificate type...

>So what's missing here???

Ouch, that sentence was quite messed up. Thanks for spotting it. It should
be IDi
instead of IDr. It is referred to the I_message (will add that). The payload
holding
the encrypted IDi is the same payload as the one holding the unencrypted IDi
(the only difference is that in the encrypted case, the payload will be
encrypted).

>Please clarify.

OK, I will look these through for the update.

Thanks,
Fredrik

PS. I'm out of office this week, so I might have some problems reading
mails.

---

From: Euchner Martin ICN M SR 3 <[email-masked]>
Date: Tue, 23 Jul 2002 18:48:12 +0200

Mats,

thanks a lot for your helpful explanations. You may want to consider stating
some rationale at least in the security consideration section, as I assume
that the arguments are not that obvious to everyone.

Another question relates to why the Diffie-Hellman protocol uses a RAND
value upon the request but not on the response. So does the RAND really
contribute any security there? Ideally, the DH-half key DHi should be
already random, assuming the xi is random. So why have two random fields
there (there is nothing wrong with having multiple random values in a
message of course)?

I have one more clarifying question/response added below inline.

With kind regards

Martin Euchner.

 -----Original Message-----
From: 	Mats Näslund [mailto:[email-masked]] 
Sent:	Tuesday, July 23, 2002 3:34 PM
To:	Fredrik Lindholm
Cc:	[email-masked]; Euchner Martin  ICN M SR 3; Mats Näslund;
[email-masked]; [email-masked];
[email-masked]
Subject:	Re: [MSEC] MIKEY-03 - some feedback

It is true that in some circumstances, updating the TGK without a new
RAND
does decrease the *total* effective key size for the keys *together*.
This assumes
that you are using transforms for which it is easy to detect key
collsions, and,
that the underlying cryptographic protocol itself does not add "nonces"
in transforms
(as e.g. SRTP does).

MEU:> So it appears that there is a certain linkage to the data security
protocol underneath. Depending on those properties, there are cases where to
better use the RAND than to leave that field out. Is that what you're
saying?

---

From: Euchner Martin ICN M SR 3 <[email-masked]>
Date: Tue, 23 Jul 2002 18:57:08 +0200

Fredrik,

thanks a lot for the quick response. A few comments added inline.

With kind regards

Martin Euchner.

 -----Original Message-----
From: 	Fredrik Lindholm [mailto:[email-masked]] 
Sent:	Tuesday, July 23, 2002 11:13 AM
To:	[email-masked]; Euchner Martin  ICN M SR 3
Cc:	Mats Naslund; [email-masked];
[email-masked]; [email-masked]
Subject:	Re: [MSEC] MIKEY-03 - some feedback

MEU:> yeah, I think not too much has been said in the current draft upon the
assumed trust models, so some further rationale might help...

MEU>: Fortunately, Mats gave some good answer

MEU:> ok I see, although I can't remember having anything seen so far
regarding encrypted IDs (at least not in the payload section). Let's await
the next MIKEY draft release then...

---

From: Euchner Martin ICN M SR 3 <[email-masked]>
Date: Wed, 24 Jul 2002 11:32:37 +0200

Mats,

thanks a  lot for the clarification. I fully agree. It was my oversight that
RAND is an input parameter to the key gen procedure, and thus I saw RAND
only isolated within the message without relationship to anything else;
sorry about that.

With kind regards

Martin Euchner.

 -----Original Message-----
From: 	Mats Näslund [mailto:[email-masked]] 
Sent:	Tuesday, July 23, 2002 8:02 PM
To:	Euchner Martin  ICN M SR 3
Cc:	Fredrik Lindholm; [email-masked]; Mats Näslund;

Hi Martin,

> that the arguments are not that obvious to everyone.

I support that. 
 
> already random, assuming the xi is random. So why have two random fields

Note: even if g^x and g^y are each perfectly random, this does *not*
imply
that g^(xy) is perfectly random, relative to someone observing g^x, g^y, 
see below.

> there (there is nothing wrong with having multiple random values in a

Take a look in Sect 4.1.4 and you will see how the RAND enters
the key generation. As you said, the RAND is there to protect against
offline
precomputation attacks, which might limit the effective key size
to half that of the TGK. Now, if the TGK is the output of a DH exchange,
it will typically be much larger than 256 bits, so even off-line
collision 
attacks would still have complexity > 2^128. On the other hand, it is
well-known that a, say 1024 bit DH key, generally has much lower entropy
than 1024 bits. For instance, if either g^x or g^y is a quadratic
residue, then
g^(xy) will automatically be a "square" too, and hence, g^x and g^y does
"leak"
information on g^(xy). Therefore, it feels uncomfortable to treat the DH
case
differently from the other two cases, "trusting" the extra entropy to be
there, 
and a uniform treatment of all three cases seems more attractive.

As for the second part of your question, it might be argued that the
initator
controlling RAND is non-symmetric since he alone controls RAND. Still,
he
does not control "your" g^y, and anyway, if you don't trust the
initator, you
should not share keys with him...  

> I have one more clarifying question/response added below inline.

[snip], OK.

> better use the RAND than to leave that field out. Is that what you're

There are protocols that might (to some extent) "make up" for lost key
entropy, 
yes. In fact, much of the key derivation functionality in MIKEY is
strictly
not needed if you use it with SRTP. For instance, MIKEY can split a key
into
an encryption key and an authentication key, but SRTP can do that too.
The reason for this is that perhaps someone is using SRTP without MIKEY,
or,
someone is using MIKEY without SRTP, and thus these options seem good to
have. We certainly don't want to *force* an SRTP implemntation to use
MIKEY.

MEU: ok, that sounds very reasonable.

Cheers

/Mats