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.
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.)
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...
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?
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'?
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.p7s
Description: S/MIME cryptographic signature
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime