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.
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.
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.
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?)
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.
4. Several references to section 5 appear to be out of date.
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.
6. You need to look at the document before it is published. Having the
document tin twice is somewhat crazy.
Jim
-----Original Message-----
From: smime-bounces(_at_)ietf(_dot_)org
[mailto:smime-bounces(_at_)ietf(_dot_)org] On Behalf
Of Herzog, Jonathan - 0668 - MITLL
Sent: Friday, April 02, 2010 11:16 AM
To: smime(_at_)ietf(_dot_)org
Cc: Khazan, Roger - 0668 - MITLL
Subject: [smime] (Another) new ID of potential interest
I would like to inform the SMIME working group of a newly-submitted
Internet Draft that may be of interest:
Use of static-static Elliptic-Curve Diffie-Hellman key agreement in
Cryptographic Message Syntax
draft-herzog-static-ecdh-00
Abstract
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.
Thus, this form of key-agreement provides authentication of sender as
well as receiver.
https://datatracker.ietf.org/doc/draft-herzog-static-ecdh/
We welcome all comments and reviews.
Thank you.
--
Jonathan Herzog
Technical Staff, MIT Lincoln Laboratory
jherzog(_at_)ll(_dot_)mit(_dot_)edu
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime