Re: [KEYPROV] MAC key support in PSKC

Hi Ming,

Choosing a separate random MAC key alleviates my main concern, of course.

I’m still not too happy that the MAC is applied to the plaintext and then encrypted, but we have already discussed this. I agree with you that there is no specific problem here. My concern is that the method – in general – is not sound, and so in the future when changing algorithms etc. there is no guarantee that a hole won’t be opened up.

All the best,

Yehuda (Andrew)

From: Pei, Mingliang [mailto:mpei at verisign.com]
Sent: Wednesday, April 29, 2009 05:12
To: Andrew Lindell; Doron Cohen; Philip Hoyer; Salah Machani; keyprov at ietf.org
Subject: MAC key support in PSKC

According to our online and offline discussions in this topic, we feel that we can come to the following proposal for MAC key support in PSKC:

1. MAC key will be randomly generated data and passed in PSKC XML in an encrypted form. The encryption uses the same encryption key and method as that for OTP secret.

This is selected over key derivation for it can handle all three key protection profiles: password based, preloaded symmetric key, and transport profile with a RSA key.

2. MAC key material can be passed in two ways:

a. it is included along with MAC algorithm.

b. it is passed along with the target secret key in a concatenated form before the result is encrypted and set in the element <Key>/<Data>/<Secret>. In other words, the key.secret.plaintext = K_MAC || key.secret and the combined value is encrypted. This is used to support the way that DSKPP protocol sets a random K_MAC.

3. The same MAC key and algorithm will be used by all key packages in a KeyContainer if it contains more than one key package.

Schema:

<xs:complexType name="KeyContainerType">
  <xs:sequence>
   <xs:element name="EncryptionKey" type="ds:KeyInfoType" minOccurs="0"/>
   <xs:element name="MACMethod" type="pskc:MACMethodType" minOccurs="0"/>
   <xs:element name="KeyPackage" type="pskc:KeyPackageType" maxOccurs="unbounded"/>
   <xs:element name="Signature" type="ds:SignatureType" minOccurs="0"/>
   <xs:element name="Extensions" type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="Version" type="pskc:VersionType" use="required"/>
  <xs:attribute name="id" type="xs:ID" use="optional"/>
</xs:complexType>

<xs:complexType name="MACMethodType">
<xs:sequence>

   <xs:choice>
   <xs:element name="MACKey" type="xenc:EncryptedValue" minOccurs="0"/>
    <xs:element name="MACKeyReference" type="xs:string" minOccurs="0"/>
   </xs:choice>
   <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>

<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType>

where

MACKey: the element carries the encrypted MAC key K_MAC.

MACKeyReference: the value is set to the KeyID of the KeyPackage inside which the K_MAC was combined with key secret before encryption.

If both are absent, the first KeyPackage is assumed to contain the MAC key in its encrypted secret field.

Example:

<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1" xmlns="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    <EncryptionKey>
        <ds:KeyName>Pre-shared-key</ds:KeyName>
    </EncryptionKey>
    <MACMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">

           <EncryptedValue>
             <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
               <xenc:CipherData>
                   <xenc:CipherValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=</xenc:CipherValue>
               </xenc:CipherData>
            </EncryptedValue>

</MACKey>

</MACMethod>
<KeyPackage>

...
<Key KeyId="12345678" KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">

            ...
            <Data>
                <Secret>
                    <EncryptedValue>
                        <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                        <xenc:CipherData>
                            <xenc:CipherValue>pgznhXdDh4LJ2G3mOY2RL7UA47yizMlXX3ADDcZd8Vs=</xenc:CipherValue>
                        </xenc:CipherData>
                    </EncryptedValue>
                    <ValueMAC>zdrZbGBj9BDZJzunbfAG3kyZyYc=</ValueMAC>
                </Secret>

...
</KeyContainer>

...
<Key KeyId="22345678" KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">

            ...
            <Data>
                <Secret>
                    <EncryptedValue>
                        <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                        <xenc:CipherData>
                            <xenc:CipherValue>qw2ewasde312asder394jwfdauiiowujfpouipgznhXdDh4LJ2G3mOY2RL7UA47yizMlXX3ADDcZd8Vs=</xenc:CipherValue>
                        </xenc:CipherData>
                    </EncryptedValue>
                    <ValueMAC>zdrZbGBj9BDZJzunbfAG3kyZyYc=</ValueMAC>
                </Secret>

...
</KeyContainer>

Comments? Thanks,

- Ming

From: Andrew Lindell [mailto:Andrew.Lindell at aladdin.com]
Sent: Sunday, March 29, 2009 9:37 PM
To: Pei, Mingliang
Cc: Doron Cohen
Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt

Dear Ming,

Either of the approaches are fine in my opinion. I also agree with Hugo that this is a good derivation function.

Thanks,

Andrew

From: Pei, Mingliang [mailto:mpei at verisign.com]
Sent: Saturday, March 28, 2009 04:42
To: Andrew Lindell; oath_technical at v2.listbox.com; keyprov at ietf.org
Cc: Doron Cohen
Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt

Hi Andrew,

Yes, we thought of using key derivation to obtain two keys from some discussions this week in IETF. The option to derive a MAC key from KEK itself is considered not a choice because in principle we don't want to use the same key for two purpose - encryption and derivation. Treating pre-shared key as a master key to derive KEK and K_MAC is a feasible choice.

When two key derivation is chosen, we would need to define KDF in PSKC, handling both password derived key and pre-shared master key. For password derived key, maybe we can use the same derivation function but different salts respectively for KEK and K_MAC. It is under discussion. Using a different KDF for pre-shared master key may add more complexity than the random chosen K_MAC. The KDF could be simply HMAC of K_master with some different constant string for KEK and K_MAC, for example, KEK = HMAC(K_master, "0000") and K_MAC = HMAC(K_master, "1111"), thanking Hugo Krawczyk for the suggestion. Alternatively PSKC can easily pass encrypted K_MAC with KEK in payload.

I favor more the random chosen K_MAC for now than the KDF approach for two keys in terms of one approach for both password and pre-shared key case. KDF is good that it doesn't need to pass additional parameter in payload. Comments are appreciated on the choice and best practices in other specifications.

Thank you,

- Ming
From: Andrew Lindell [mailto:Andrew.Lindell at aladdin.com]
Sent: Monday, March 23, 2009 11:13 PM
To: Pei, Mingliang; oath_technical at v2.listbox.com; keyprov at ietf.org
Cc: Doron Cohen
Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt

Hi Ming,

Thank you for your response. One thing however is not clear to me now. Is the hashed key (ValueMAC) encrypted together with the key? If yes, then I agree with you that it’s not really a concern. This also solves the problem of integrity (albeit not cryptographically, where a MAC is really needed). However, if the hashed value is not encrypted, then this can be a problem if someone uses a procedure that results in a relatively low entropy key. Although such a procedure within itself is bad, this would make it worse and so it would be better to encrypt the hashed value as well.

One other thing, regarding item (1). When two keys cannot be provided, have you thought of using key derivation to obtain two keys from the one. Although you keep the same entropy, this is more cryptographically sound than using the same key for both tasks.

Thanks,

Andrew

From: Pei, Mingliang [mailto:mpei at verisign.com]
Sent: Tuesday, March 17, 2009 04:29
To: Pei, Mingliang; oath_technical at v2.listbox.com; keyprov at ietf.org
Cc: Andrew Lindell
Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt

Copying keyprov mailing list... - Ming
From: Pei, Mingliang
Sent: Monday, March 16, 2009 7:26 PM
To: Pei, Mingliang; 'oath_technical at v2.listbox.com'
Cc: 'Andrew Lindell'
Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt

I need to clarify that the strong hash is good when the cleartext to be encrypted is some long random secret bytes. If the value is within some known finite integer values, some simple hash lookup over all possible values will reveal the cleartext itself.

Thanks,

- Ming
From: Pei, Mingliang
Sent: Monday, March 16, 2009 7:22 PM
To: oath_technical at v2.listbox.com
Cc: Andrew Lindell
Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt

Hi Doron and Andrew,

Thank you very much for the review and comments.

1. It is actually a working item in the draft per earlier comment. We agree with you that using the same key for MAC and encryption isn't a good practice. We thought of options that allow one to specify a separate MAC key by extending the current definition on the MAC algorithm type. Asking two keys isn't ideal for those pre-shared encryption key devices. In DSKPP, a MAC key was randomly generated and encrypted along with the secret. We have not had deep discussions on this. Thank you for raising the issue, and it will help us to make sure it is addressed in the final version.

2. The purpose of the ValueMAC is to serve integrity check of the data. It isn't intended for any sender authentication. On one hand, our initial version simply pass a hash value of the data to be encrypted, for example, ValueMAC = SHA_256(cleartext). Note that hashing over ciphertext doesn't serve the purpose. A man-in-the-middle may alter the ciphertext and generate hash accordingly. Therefore it is necessary to calculate it over the cleartext.

When HMAC was chosen for the integrity check purpose, we still felt that the hash over the original data was good. The essential argument goes back to the first item: should the MAC key be a separate one. If it is a separate one, the security concern doesn't seem to exist.

For simplicity, I consider that SHA_256(cleartext) is fine without requiring complexity in choosing MAC key for HMAC. Using the same key again isn't good. There are other ways to serve the integrity check, for example, encryption is over <cleartext> + <Encrypted(random data) with the cleartext>. The simpliest is <hash(cleartext)> with a strong hash function such as SHA_256. I don't think a strong hash and encrypted value together will reveal the cleartext.

Suggestions are welcomed for making this choice.

Thank you,

- Ming
From: Doron Cohen [mailto:doronc at aladdin.com]
Sent: Thursday, March 05, 2009 4:58 AM
To: oath_technical at v2.listbox.com
Cc: Andrew Lindell; oath_technical at v2.listbox.com
Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt

Hi Philip,

Below are a couple of comments I received from Aladdin’s Chief Cryptographer, Yehuda (Andrew) Lindell . Yehuda will be glad to provide more clarifications if required.

“When algorithms without integrity checks are used, such as AES-128-CBC, a keyed MAC value using the same key as the key encryption key MUST be placed in the <ValueMAC> element of the <Data> element. In this case the MAC algorithm type MUST be set in the <MACAlgorithm> element of the <KeyContainer> element. Implementations of PSKC MUST support HMAC-SHA1 (with the URI of http://www.w3.org/2000/09/xmldsig#hmac-sha1) as the mandatory-to-implement MAC algorithm.

[Yehuda Lindell] This is very bad practice. You should not use the same key for different tasks. The solution to this (where an authenticated-encryption scheme is not used) is to use key derivation to obtain two keys from the single one, and then use the first for encryption and the second for the MAC.

In section 4.2 the following appears:
Additionally, a <ValueMac> element, which is populated with a MAC generated from the unencrypted value in case the encryption algorithm does not support integrity checks, MAY be included as a child element.  The example shown at Figure 2 illustrates the usage of the <Data> element with two child elements, namely <Secret> and <Counter>.  Both elements carry plaintext value within the <PlainValue> child element.
[Yehuda Lindell] This says that the MAC is applied to the unencrypted value. This is bad practice (it is not always secure) and it’s far better to generate the MAC by applying it to the encrypted ciphertext. In any case, this contradicts what appears below in Section 6.1 (Section 6.1 explicitly states that the MAC is applied to the encrypted value, which is the correct way to work).

Best Regards

Doron

Doron Cohen

CTO, Authentication Business Unit

Aladdin Knowledge Systems

From: Philip Hoyer [mailto:philip.hoyer at actividentity.com]
Sent: Tuesday, February 24, 2009 22:14
To: oath_technical at v2.listbox.com
Subject: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt

Ladies and Gentlemen:

Could I invite the participants on the list please to review the PSKC spec as below as the work started in OATH and it would be great to see what you think of it now.

Philip

From: keyprov-bounces at ietf.org [mailto:keyprov-bounces at ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Monday, February 23, 2009 12:14 PM
To: KEYPROV
Subject: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt

Hi all,

this is a KEYPROV Working Group Last Call for comments on
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-02.txt

Please send your comments to the list by March 6, 2009.

Ciao
Hannes & Phillip

oath_technical | Archives | Modify Your Subscription

**************************************************************************************************
The contents of this email and any attachments are confidential.
It is intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or? the
sender immediately and do not disclose the contents to anyone or make copies.
** eSafe scanned this email for viruses, vandals and malicious content **
**************************************************************************************************

oath_technical | Archives | Modify Your Subscription
**************************************************************************************************
The contents of this email and any attachments are confidential.
It is intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or the
sender immediately and do not disclose the contents to anyone or make copies.
** eSafe scanned this email for viruses, vandals and malicious content **
**************************************************************************************************
**************************************************************************************************
The contents of this email and any attachments are confidential.
It is intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or the
sender immediately and do not disclose the contents to anyone or make copies.
** eSafe scanned this email for viruses, vandals and malicious content **
**************************************************************************************************