Re: (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.

   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:  [email protected]
MIT Lincoln Laboratory               			www:    http://www.ll.mit.edu/CST/
244 Wood Street    
Lexington, MA 02420-9185

_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime