I can easily understand how these things slip out. I needed to find the
document in order to figure out what I was thinking of when I wrote some of
this.
Some comments in-line
-----Original Message-----
From: Herzog, Jonathan - 0668 - MITLL
[mailto:jherzog(_at_)ll(_dot_)mit(_dot_)edu]
Sent: Tuesday, August 03, 2010 11:48 AM
To: Jim Schaad
Cc: Khazan, Roger - 0668 - MITLL; smime(_at_)ietf(_dot_)org
Subject: Re: [smime] (Another) new ID of potential interest
Oh, goodness. Have I really let this lie, unanswered, for almost four
months? Yes, yes I have. My apologies. In any case, let me reply to
your concerns:
On Apr 10, 2010, at 8:31 PM, Jim Schaad wrote:
Gentlemen,
I have been reviewing this document I would like to suggest that it
is
either overgenerous in the set of cryptographic services that are
provided
or missing some pre-conditions that are necessary in order to obtain
those
services.
In section 1 states that one of the services that is available is
sender-authentication, however no restrictions are placed on when
this
service is available anyplace in the document that I can find. I
would like
to suggest that is this not actually either a very strong service or
one
that is always available.
Please consider the following sequence of actions:
1. Alice sends a static-static Authenticated message to both Bob and
Mallory. Alice will use a static-static DH method to transport the
key to
Bob, it does not really matter what technique is use to transport the
key to
Mallory. The important thing is just that this is one message and
thus one
authentication key.
2. Mallory intercepts the message and prevents Bob from receiving
it.
3. Mallory creates a new message using the same authentication key
that
Alice generated to authenticate a new message. Mallory may or may
not
include himself as a recipient of the message.
4. Mallory sends the new message to Bob.
5. Bob receives the message, validates the static-static DH works
and
authenticates the message. Bob now believes that Alice was the
original
sender of the message.
There is a difference in services one gets between an online protocol
and a
store-and-forward protocol. For on-line you only ever get a pair-
wise
operation and you have the immediate check that the negotiation was
successful. This is lacking for the store-and-forward versions.
This difference is only relevant if you are looking for
sender-authentication of the messages that are sent. Thus there are
never
an issue for an ephemeral-static version of the protocols. Mallory
could
run the same sequence as above, but since there is no reason for Bob
to
believe that Alice sent the message, there is not a strong attack.
This is entirely correct, and an embarrassing oversight on our part.
Your attack works entirely as advertised, and it is incorrect for us to
claim that our proposal provides 'sender authentication.'
In order to get a sender-authentication of a message one needs to do
the
following:
1. Mandate in any protocol using this that only a single Recipient
Info can
ever occur in a message.
2. Mandate that the ukm be present in the message and,
3. Mandate that a timeliness element be included in the ukm.
In any event, the sender-authentication can never be taking to a
third party
for verification since either party could have constructed the
message. Bob
in fact could construct a message despite the fact that Alice has
never sent
a message to Bob.
Those are all good suggestions, but I think that we will take another
approach entirely: dropping the claim of sender authentication. Sender
authentication, was never our goal, actually. Rather, our goal was to
provide a way for the message-sender to use a certified elliptic-curve
Diffie-Hellman key. If we get that but not sender authentication, well,
then so be it.
Therefore, we propose the following changes:
* Change the abstract to:
"This document describes how to use 'static-static' Elliptic Curve
Diffie-Hellman key-agreement with the Cryptographic Message Syntax.
In this form of key-agreement, the Diffie-Hellman values of both
sender and receiver are long-term values contained in certificates."
* In section 1 (at the end), we change:
We note that like ephemeral-static ECDH, static-static ECDH creates
a
secret key shared by sender and receiver. Unlike ephemeral-static
ECDH, however, static-static ECDH uses a static key pair for the
sender and therefore allows for the verification of the sender's
identity. Each of the three CMS structures discussed in this
document (EnvelopedData, AuthenticatedData, and AuthEnvelopedData)
use these properties of static-static ECDH to achieve different
goals:
o EnvelopedData uses static-static ECDH to provide data
confidentiality. It will not necessarily, however, provide
either
sender-authentication or data integrity.
o AuthenticatedData uses static-static ECDH to provide sender-
authentication and data-integrity. It will not necessarily,
however, provide confidentiality for the data.
o AuthEnvelopedData uses static-static ECDH to provide all of
confidentiality, sender-authentication, and data-integrity.
to
We note that like ephemeral-static ECDH, static-static ECDH creates
a
secret key shared by sender and receiver. Unlike ephemeral-static
ECDH, however, static-static ECDH uses a static key pair for the
sender. Each of the three CMS structures discussed in this
document (EnvelopedData, AuthenticatedData, and AuthEnvelopedData)
use static-static ECDH to achieve different goals:
o EnvelopedData uses static-static ECDH to provide data
confidentiality. It will not necessarily, however, provide data
integrity.
o AuthenticatedData uses static-static ECDH to provide
data-integrity. It will not necessarily,
however, provide confidentiality for the data.
It will not provide confidentiality for the data. I would suggest removal
or amendment of the second sentence.
o AuthEnvelopedData uses static-static ECDH to provide both of
confidentiality and data-integrity.
* In Section 5, we change
AuthenticatedData or AuthEnvelopedData messages, on the other hand,
are not given any form of ECDH by [CMS-ECC]. This is appropriate:
it
defines only ephemeral-static Diffie-Hellman, and this form of
Diffie-Hellman does not (inherently) provide any form of sender-
authentication. This document, on the other hand, requires that the
sender use a certified public value. Thus, this form of key-
agreement provides implicit key authentication and, therefore,
authentication of the sender.
to
AuthenticatedData or AuthEnvelopedData messages, on the other hand,
are not given any form of ECDH by [CMS-ECC]. This is appropriate:
it
defines only ephemeral-static Diffie-Hellman, and this form of
Diffie-Hellman does not (inherently) provide any form of data-origin
authentication. This document, on the other hand, requires that the
sender use a certified public value. Thus, this form of key-
agreement provides implicit key authentication and, under some
circumstances, data-origin authentication. (See Section 7.)
* In Section 7, we describe the attack you provide above. (Do you mind
if I use your text as a starting point?) We then explain that data-
origin cannot be guaranteed unless it is a priori guaranteed that the
message be sent by the sender to exactly one recipient. And if that's
not the case, data-origin must be provided by some other mechanism
(such as digital signatures.)
You can steal the text wholesale for all I care.
Other comments:
1. As written the ukm descriptions are incorrect. For section 2.1 -
the
correct order is. If ukm is present, it contains the ECC-CMS-
SharedInfo
structure. If the user wants to add a random value, it is placed in
the
entityUInfo field of this structure.
I don't quite understand. RFC 5652 defines ukm as being a
UserKeyingMaterial, which is then defined to be an OCTET STRING. What
do you mean, then, when you say that ukm contains a structure?
BTW, the text in our draft, as submitted, mirrors the analogous section
from RFC 5753:
...The ukm is
placed in the entityUInfo field of the ECC-CMS-SharedInfo
structure. When present, the ukm is used to ensure that a
different key-encryption key is generated, even when the
ephemeral
private key is improperly used more than once, by using the ECC-
CMS-SharedInfo as an input to the key derivation function...
You are correct - that is the way it is written. I need to find some really
old code to find out if it is written correctly or if there is a problem in
how it is done. For now please ignore this comment.
2. The bullet list in section 2.2. lists the ukm twice. (The first
bullet
here is vastly confusing - perhaps a error in doing updates?
Oops. Yes, this was a minor edit gone wrong. The list should read:
o an integer "keydatalen", which is
the KeyWrapAlgorithm symmetric key-size in bits, and
o the value of ukm, if used.
3. Note 3278bis appears to have been published in January of this
year, so
saying that the update is a work in progress appears to be
significantly out
of date.
Thanks. We can actually remove the whole comment, since it is now moot.
4. Several references to section 5 appear to be out of date.
Thanks. Will fix.
5. You need to supply an ASN.1 module. I have a personal preference
to one
that uses the new ASN.1 but could live with an 88 module if
necessary.
Doing so might expose some deficiencies in the document.
Do you really think so? We don't define any new ASN.1 structures or
values. But if you do think that we need to provide an ASN.1 module,
then please help me understand what you envision. What would this
module contain that's not already in other modules, such as the one in
Section 12.1 of RFC 5652?
Sorry - I thought that I had seen some OIDs defined by this document - but
they appear to have been defined in RFC 5753 so no you do not need a module.
6. You need to look at the document before it is published. Having
the
document tin twice is somewhat crazy.
I'm sorry, but what is the 'document tin'?
Sorry - if you look at the document on line, then there are two copies of
the document in the .txt file.
Thanks again for your help.
--
Jonathan Herzog
voice: (781)
981-2356
Technical Staff fax:
(781)
981-7687
Cyber Systems and Technology Group email:
jherzog(_at_)ll(_dot_)mit(_dot_)edu
MIT Lincoln Laboratory www:
http://www.ll.mit.edu/CST/
244 Wood Street
Lexington, MA 02420-9185
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime