Re: [jose] Use of AES-HMAC algorithm

Concat is what McGrew algorithm does it, is it not? I support the move.

2013/4/9 Matt Miller (mamille2) <mamille2@cisco.com>:
> +1 on a longer key.
>
>
> - m&m
>
> Matt Miller < mamille2@cisco.com >
> Cisco Systems, Inc.
>
> On Apr 7, 2013, at 10:47 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>
>> FWIW: I'd strongly prefer a longer key than a different KDF scheme.
>>
>> On Apr 7, 2013, at 12:32 PM, "Peck, Michael A" <mpeck@mitre.org> wrote:
>>
>>> I prefer using a KDF, as I think the approach of using a long key over-complicates key management by requiring generation and transport of a longer key than necessary, and it may also provide a false sense of the overall security level.
>>>
>>> As previously discussed, the Concat KDF is not appropriate, but there are other NIST KDFs that seem acceptable for this key expansion purpose.
>>> For instance, the "KDF in Counter Mode" in NIST SP 800-108 Section 5.1, with the PRF algorithm set to the same HMAC algorithm used in the corresponding AEAD algorithm.  (i.e. use HMAC-SHA-256 as PRF with AES-128 + HMAC-SHA-256, and use HMAC-SHA-512 as PRF with AES-256 + HMAC-SHA-512).
>>>
>>> For example, for AES-128 + HMAC-SHA-256, where "key" is an inputted 128-bit "master" key:
>>> Expanded key = HMAC-SHA-256(key, 0x00 0x00 0x00 0x01 | "A128CBC+HS256" | 0x00 | 0x00 0x00 0x01 0x00)
>>> AES key = first 128 bits of expanded key
>>> HMAC key = second 128 bits of expanded key
>>>
>>> If JOSE chooses to use draft-mcgrew-aead-aes-cbc-hmac-sha2, I think it would be worth discussing with the draft authors whether they are interested in performing the KDF in the AEAD algorithm itself (for example, input a 128-bit key into their AEAD_AES_128_CBC_HMAC_SHA_256 and have it be responsible for deriving the 128-bit AES key and 128-bit HMAC key).
>>>
>>> Mike
>>>
>>>> -----Original Message-----
>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
>>>> Jim Schaad
>>>> Sent: Thursday, April 04, 2013 7:51 PM
>>>> To: jose@ietf.org
>>>> Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request
>>>>
>>>> <chair>
>>>>
>>>> At the request of the editors, this is a formal consensus call on the first
>>>> item in the list below.  If there are objects to use a single long key
>>>> rather than a KDF function for the AES-CBC/HMAC algorithm please speak up
>>>> now.  To date nobody has said that I was wrong to assume the consensus on
>>>> that item.
>>>>
>>>> Call ends in one week.
>>>>
>>>> Jim
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
>>>> Jim
>>>>> Schaad
>>>>> Sent: Wednesday, March 27, 2013 3:21 PM
>>>>> To: jose@ietf.org
>>>>> Subject: [jose] Use of AES-HMAC algorithm
>>>>>
>>>>> <chair>
>>>>> After spending time looking at and thinking about how to resolve this
>>>> issue
>>>>> since I was unable to do so at the last F2F meeting.  I have come up with
>>>> the
>>>>> following set of issues that might need to be addressed as part of
>>>> resolving
>>>>> this issue.
>>>>>
>>>>> 1.  Do we change from using KDC to having a double size key for the
>>>>> algorithm?  I think that there is probably a consensus that this should be
>>>> done.
>>>>>
>>>>> 2. Should IVs be prepended to the encrypted body as part of the encoding
>>>>> steps?  If so then this change should be universal.
>>>>>
>>>>> Doing so would eliminate one field from all of the encoding formats which
>>>>> should be considered a plus.
>>>>> Doing so would force code writers to understand how large the IV is for
>>>> all
>>>>> algorithms as the IV would no longer be a separate item.
>>>>>
>>>>> 3. Should Authentication Tags be appended to the encrypted body as part of
>>>>> the encoding steps?
>>>>>
>>>>> Doing so would eliminate one field from all of the encoding formats which
>>>>> should be considered a plus.
>>>>> Doing so would force code writers to understand how large the IV is for
>>>> all
>>>>> algorithms as the IV would no longer be a separate item.
>>>>> Doing so would force a re-organization for the multiple recipient case as
>>>>> either all recipient specific data would need to be excluded from the
>>>>> authentication step or all of the recipient data would need to be included
>>>> for
>>>>> by all recipients.
>>>>> Changing how the recipient info is process is going to give a performance
>>>>> benefit for sending encrypted items for multiple recipients.
>>>>> The current strategy of a single IV and key pair with AES-GCM and
>>>> different
>>>>> authentication data needs to have CFRG look at it.  I am worried that it
>>>> might
>>>>> be a serious security flaw.
>>>>>
>>>>> 4. Should we reference the McGrew draft and provide text on how things
>>>> are
>>>>> changed or should we "copy" the draft into our text?
>>>>>
>>>>> 5.  If we allow for the use of AES-GCM or AES-HMAC for doing key wrapping,
>>>>> does this change how we think about any of the above questions?
>>>>>
>>>>> Allowing for AES-GCM for key wrapping has a benefit for hardware
>>>> situations
>>>>> as only the encrypt and not the decrypt functions need to be placed in
>>>>> hardware.  However allowing for this key wrapping give a problem as there
>>>> is
>>>>> no way to encode the three fields into the encrypted value unless with use
>>>>> either a JSON structure in this location or we do use the single appended
>>>>> binary output stream.  The first approach leads to an expansion of the
>>>> field by
>>>>> double base64 encoding which is highly undesirable.
>>>>>
>>>>> Jim
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jose mailing list
>>>>> jose@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>
>>>> _______________________________________________
>>>> jose mailing list
>>>> jose@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/jose
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en