RE: How does one specify the Salt/Nonce for ConcatKDF key derivation in XML encryption 1.1

My reading of this paragraph was when the same message was being sent to multiple recipients. Perhaps instead change to:

"When ECDH is used in Ephemeral-Static (ES) mode, the recipient has a static key pair, but the sender generates a ephemeral key pair for each message. For a given message, the same ephemeral key may be used when there are multiple recipients that use the same curve parameters."
?

-- Magnus

From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org] On Behalf Of Pratik Datta
Sent: Monday, October 17, 2011 9:28 AM
To: public-xmlsec@w3.org
Subject: RE: How does one specify the Salt/Nonce for ConcatKDF key derivation in XML encryption 1.1

Based on Elaine's input, I propose that we remove the second line from this paragraph from Section 5.6.4

"When ECDH is used in Ephemeral-Static (ES) mode, the recipient has a static key pair, but the sender generates a ephemeral key pair for each message. The same ephemeral key may be used when there are multiple recipients that use the same curve parameters."
We should not recommend people to use reuse the ephemeral key.

Pratik

From: Pratik Datta
Sent: Tuesday, October 11, 2011 11:37 AM
To: Barker, Elaine B.
Cc: public-xmlsec@w3.org<mailto:public-xmlsec@w3.org>
Subject: RE: How does one specify the Salt/Nonce for ConcatKDF key derivation in XML encryption 1.1

Thanks Elaine,
I am sending your response to the XML security list.

Pratik


From: Barker, Elaine B. [mailto:elaine.barker@nist.gov]<mailto:[mailto:elaine.barker@nist.gov]>
Sent: Tuesday, October 11, 2011 11:30 AM
To: Pratik Datta
Subject: FW: How does one specify the Salt/Nonce for ConcatKDF key derivation in XML encryption 1.1

Sorry not to get back to you sooner, but I needed to coordinate my response.

It is true that different keys would be derived when using the same ephemeral key with different static keys. In 56A, the use of the same ephemeral key is allowed in broadcast situations, but this is not the same as what the document is proposing - to perform key agreement with multiple recipients to send different messages. For broadcast scenarios, the intent is to send the same information to multiple recipients more or less simultaneously. Reuse of the ephemeral key loses some of the security properties discussed in Section 6.2.2.3 of SP 800-56A, that is:

  1.  The initiator has no assurance that a previous shared secret has not been reused, and
  2.  A compromise of the ephemeral private key (of the initiator) could compromise all transactions in which the ephemeral key is used - both past and future.

Elaine

From: Pratik Datta <pratik.datta@oracle.com>
Date: Tue, 4 Oct 2011 14:30:35 -0400
To: Magnus Nystrom <mnystrom@microsoft.com>, <public-xmlsec@w3.org>
Cc: "Elaine. Gov" <elaine.barker@nist.gov>, "Chen, Lily" <lily.chen@nist.gov>
Subject: RE: How does one specify the Salt/Nonce for ConcatKDF key  derivation in  XML encryption 1.1

Including Elaine and Lily in the email discussion.


Elaine, Lily
XML Encryption 1.1  references the ConcatKDF key derivation algorithm of NIST SP 800-56A
See section 5.4.1 http://www.w3.org/TR/xmlenc-core1/#sec-ConcatKDF
and section 5.6.4 http://www.w3.org/TR/xmlenc-core1/#sec-ECDH-ES


Section 5.6.4 spec says
"When ECDH is used in Ephemeral-Static (ES) mode, the recipient has a static key pair, but the sender generates a ephemeral key pair for each message. The same ephemeral key may be used when there are multiple recipients that use the same curve parameters."


Is it ok to reuse the ephemeral key ?


RFC2631
http://tools.ietf.org/html/rfc2631#section-2.3
says this about DH- Ephemeral-Static mode

In Ephemeral-Static mode, the recipient has a static (and certified)
   key pair, but the sender generates a new key pair for each message
   and sends it using the originatorKey production. If the sender's key
   is freshly generated for each message, the shared secret ZZ will be
   similarly different for each message and partyAInfo MAY be omitted,
   since it serves merely to decouple multiple KEKs generated by the
   same set of pairwise keys. If, however, the same ephemeral sender key
   is used for multiple messages (e.g. it is cached as a performance
   optimization) then a separate partyAInfo MUST be used for each
   message. All implementations of this standard MUST implement
   Ephemeral-Static mode.



Is this advice applicable for ECDH-ES as well?
I.e. should we recommend people to use partyUInfo and specify a nonce if the ephemeral key is cached and reused?

Is it computationally expensive to generate a new ephemeral key every time? or does caching make sense?





Magnus,
I am not very clear what you mean by "static-static".  In XML Encryption 1.1 we only have "ephemeral-static",  If the ephemeral key is cached , does that make is static-static?


Pratik

-----Original Message-----
From: Magnus Nystrom [mailto:mnystrom@microsoft.com]
Sent: Monday, October 03, 2011 7:58 PM
To: XMLSec WG Public List (public-xmlsec@w3.org)
Subject: RE: How does one specify the Salt/Nonce for ConcatKDF key derivation in XML encryption 1.1

Responding to myself here, one suggestion that has been made to me off-list is to provide a note on what to do in static-static situations. This may be reasonable and here's a suggestion:

In Section 5.4.1 of XML Encryption 1.1, change:

The AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo and SuppPrivInfo attributes are as defined in [SP800-56A]. Their presence is optional but AlgorithmID, PartyVInfo and PartyUInfo must be present for applications that need to comply with [SP800-56A].

To:

The AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo and SuppPrivInfo attributes are as defined in [SP800-56A]. Their presence is optional but AlgorithmID, PartyVInfo and PartyUInfo must be present for applications that need to comply with [SP800-56A]. Note: The PartyUInfo component shall include a nonce when ConcatKDF is used in conjunction with a static-static Diffie-Hellman (or static-static ECDH) key agreement scheme; see further [SP800-56A].

-- Magnus

> -----Original Message-----
> From: Magnus Nystrom
> Sent: Tuesday, September 27, 2011 8:44 PM
> To: XMLSec WG Public List (public-xmlsec@w3.org)
> Subject: RE: How does one specify the Salt/Nonce for ConcatKDF key derivation
> in XML encryption 1.1
>
> Hi Pratik,
> In the case of static-static D-H, the nonce shall be part of the PartyUInfo
> element (see NIST 800-56A: "NonceU shall be in the PartyUInfo subfield of
> OtherInfo"). As we state in the document that these attributes are defined in
> 800-56A, I don't think there's a need to make an update here.
>
> Best,
> -- Magnus
>
> > > Resent-From: <public-xmlsec@w3.org>
> > > From: ext Pratik Datta <pratik.datta@oracle.com>
> > > Date: September 19, 2011 4:18:01 PM EDT
> > > To: <public-xmlsec@w3.org>
> > > Subject: How does one specify the Salt/Nonce for ConcatKDF key
> > > derivation in XML encryption 1.1
> > >
> > > I noticed that the Legacy key derivation function has a <KA-Nonce>
> > > element,
> > PBKDF2  has a <Salt> element, but there is nothing equivalent of this
> > for ConcatKDF.
> > > Is the salt supposed to be part of PartyUInfo , PartyVInfo ?
> > >
> > >
> > > The SP800-56A  says this:
> > > ------
> > > 3.2 PartyUInfo: A bit string containing public information that is
> > > required by the application using this KDF to be contributed by
> > > party U to the key derivation process. At a minimum, PartyUInfo
> > > shall include IDU, the identifier of party U. See the notes below.
> > >
> > > 3.3 PartyVInfo: A bit string containing public information that is
> > > required by the application using this KDF to be contributed by
> > > party V to the key derivation process. At a minimum, PartyVInfo
> > > shall include IDV, the identifier of party V. See the notes below.
> > > -----
> > >
> > > I am not very clear from this text whether PartyUInfo is supposed
> > > include
> > some random value.
> > >
> > > Without the salt, the derived key will turn out to be same every time.
> > >
> > >
> > > Pratik
> > >
> >




------ End of Forwarded Message


------ End of Forwarded Message