Re: [jose] FW: FW: Issue #54, #55, #141

["Jim Schaad" <[e-mail]>]

Per the last call, I had said that I had a different proposal for how to
address these issues and it was to be reviewed by the list.  This text does
not say the same thing as what is currently in the text.

 

Jim

 

 

From: Mike Jones [mailto:[e-mail]] 
Sent: Monday, October 28, 2013 12:19 PM
To: Jim Schaad; [e-mail]
Subject: RE: [jose] FW: FW: Issue #54, #55, #141

 

#54:  Richard had agreed to close this as "wontfix" and this was confirmed
on the last call.  Please close this one.

 

#55:  The working group text discussed on the list has been incorporated in
the drafts.  Please close this one as "fixed".

 

#151:  Per our discussion during our last meeting in my office, our use of
Concat is specific to ECDH key agreement - and not intended to
general-purpose.  Concat is already described in a general-purpose way in
NIST 800-56A so we don't need to repeat that description in JWA.  Given that
the technical issue of giving the algorithm name a length prefix has been
addressed, I believe that it's time to close this one as "fixed" (which I
think you agreed to do in my office, after the length prefix was added).

 

There is also already text saying how to achieve the same effect as RFC 2631
in a note.  Thus, I believe that all these issues have already been
addressed.

 

                                                                -- Mike

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Jim
Schaad
Sent: Saturday, October 26, 2013 4:43 PM
To: [e-mail]
Subject: [jose] FW: FW: Issue #54, #55, #141

 

I have not seen comments on this

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Jim
Schaad
Sent: Monday, October 07, 2013 5:01 PM
To: [e-mail]
Subject: [jose] FW: Issue #54, #55, #141

 

 

 

From: Jim Schaad [mailto:[e-mail]] 
Sent: Tuesday, October 01, 2013 3:41 PM
To: [e-mail]
Subject: Issue #54, #55, #141

 

There are four issues that need to be addressed with respect to the concat
section of the JWA draft.  There is some agreement for these issues but I am
not totally happy with what is being done here and would like to see some
changes.  This message describes the changes that I would like to see.

 

The current set of open issues in the tracker are:

 

Issue #54 - epk/apu/apv need to be REQUIRED

Issue #55 - Mandatory entropy in ECC KDF inputs

Issue #151 - Section 4.7.2 Concat should have its own section

No Tracker Item - The concat usage should be consistent with that of the CMS
DH document RFC 2631

 

 

I don't like the current text which says that the partyU name can be either
a name or a nonce value.  While it is true that both are not needed for the
ES version of the key derivation function, this will not be the case for a
SS version of using concat.  I would like to make sure that this is a doable
thing without having to do massive re-writes.  I therefore propose the
following changes:

 

Add a new section

 

4.7.1.4 "nonce" Header Parameter

 

The "nonce" value for a key derivation algorithm.  This parameter is
REQUIRED to be used when a static-static key agreement method is used and
MAY be used for other key agreement methods.  The value MUST be generated
freshly for each key derivation done.  The member value contains the base64
encoded nonce value.  The length of the nonce value needs to be sufficient
that it will not be duplicated for the pair of keys being used.  If the
uniqueness is generated pseudo-randomly, then it should be a minimum of 512
bits long.

 

Change the way that PartyUInfo is defined in section 4.7.2 as follows:

 

PartyUInfo  The PartyUInfo value consists of the partyU name and, when
present, the nonce field.  Both fields are encoded as Datalen || Data, where
Datalen is a 32 bit value containing the size of the field in bits as a
big-endian integer and Data is the value of the field.

 

      PartyUInfo = I4(partyU name.length) || partyU name

      If nonce.length > 0 then PartyUInfo = PartyUInfo || I4(nonce.length)
|| nonce

 

 

Replace the last paragraph with

 
The "apu" and "apv" parameters MUST contain distinct values so that the same
key would not be generated if the KDF is done for the opposite direction.
Applications can change the default values for these parameters in order to
make the keys generated for that application different from other
applications.

 

 

 

My reading of the NIST document which we are using for concat says that the
partyU name and partyV names are required to be defined, however they can be
defined by the protocol and not by the actual parties themselves.  This
means that it is possible that the parameters can have values, without them
being transmitted as part of the message.  In fact they should be removable
by the application and not transmitted.  I don't know that we need to make
that an explicit statement in the text or not.  (I have chosen not to do so
in this change, but it can be discussed.) Based on this understanding I
would like to modify the text in the following ways.

 

 

Change the way that PartyUInfo and partyVInfo are defined in section 4.7.2
as follows:

 

Old: 

 

If an "apu" (agreement PartyUInfo) header

      parameter is present, Data is set to the result of base64url

      decoding the "apu" value and Datalen is set to the number of

      octets in Data.  Otherwise, the Datalen is set to 6 and Data is set to
the UTF-8 encoded string "Sender".

 

For apv replace "Sender" with "Recipient"

 

 

 

In order that the concat description be available for other key agreement
algorithms (i.e. ES-DH or SS-ECDH) I really would like to see it described
as a separate algorithm that is then referred to from the ES-ECDH algorithm
description.  This means that apu, apv and nonce would be defined as being
CONCAT parameters and not be defined as ES-ECDH parameters.   This can be
discussed and I can provide the alternate text if it makes sense to do so.

 

Jim