Re: [KEYPROV] New version of PSKC

Magnus and Ming,

In view of the new xmlenc11 and the below thread could you please review and suggest a resolution for use of PBE in PSKC.

This is the last issue for PSKC and I want to close this asap.

Also please note that the xenc11 spec states that a PRF SHALL be present:

The PBKDF2 key derivation algorithm is defined in PKCS #5 [PKCS5] and an XML schema for its parameters is defined in PKCS #5 v2.0 Amd. 1 [PKCS5Amd1]. The pkcs-5:PBKDF2-params element type defined in the latter document shall be used as a child of xenc11:KeyDerivationMethod when using this key derivation algorithm. Also, the Algorithm attribute of the pkcs-5:PRF element SHALL be present. It is RECOMMENDED to use HMAC-SHA256 as the PRF algorithm (see [XML-DSIG], [HMAC] ).

An example of an xenc11:DerivedKey element with this key derivation algorithm is:

<xenc11:DerivedKey

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"

  xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"

  xmlns:pkcs-5="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#">

  <xenc11:KeyDerivationMethod

    Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">

    <pkcs-5:PBKDF2-params>

      <Salt>

        <Specified>Df3dRAhjGh8=</Specified>

      </Salt>

      <IterationCount>2000</IterationCount>

      <KeyLength>16</KeyLength>

      <PRF Algorithm="http://www.w3.org/2001/04/xmldsig-more#hmac-sha256"/>

    </pkcs-5:PBKDF2-params>

  </xenc11:KeyDerivationMethod>

  <xenc:ReferenceList>

    <xenc:DataReference URI="#ED"/>

  </xenc:ReferenceList>

  <xenc11:MasterKeyName>Our shared secret</xenc11:MasterKeyName>

</xenc11:DerivedKey>

Whereas we have in the current spec:

<pskc:KeyContainer

xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"

xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"

xmlns:pkcs5=

"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"

xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Version="1.0">

<pskc:EncryptionKey>

<xenc11:DerivedKey>

<xenc11:KeyDerivationMethod

Algorithm=

"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf2">

<pkcs5:PBKDF2-params>

<Salt>

<Specified>Ej7/PEpyEpw=</Specified>

</Salt>

<PRF/>

</pkcs5:PBKDF2-params>

</dkey:KeyDerivationMethod>

<xenc:ReferenceList>

<xenc:DataReference URI="#ED"/>

</xenc:ReferenceList>

<xenc11:MasterKeyName>My Password 1</xenc11:MasterKeyName>

</xenc11:DerivedKey>

</pskc:EncryptionKey>

…..

Which does NOT have a PRF.

Thanks,

Philip

------- New sample ----------------------------

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<pskc:KeyContainer xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#" xmlns:pkcs5="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" Version="1.0" Id="KC0002">

<pskc:EncryptionKey>

<dkey:DerivedKey>

<dkey:KeyDerivationMethod Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf2">

<pkcs5:PBKDF2-params>

<Salt>

<Specified>Ej7/PEpyEpw=</Specified>

</Salt>

</pkcs5:PBKDF2-params>

</dkey:KeyDerivationMethod>

<xenc:ReferenceList>

<xenc:DataReference URI="#ED"/>

</xenc:ReferenceList>

<dkey:MasterKeyName>Passphrase1</dkey:MasterKeyName>

</dkey:DerivedKey>

</pskc:EncryptionKey>

<pskc:MACMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">

<pskc:MACKey>

<xenc:EncryptionMethod Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">

<pskc:EncryptionScheme Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>

</xenc:EncryptionMethod>

<xenc:CipherData>

<xenc:CipherValue>2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx</xenc:CipherValue>

</xenc:CipherData>

</pskc:MACKey>

</pskc:MACMethod>

<pskc:KeyPackage>

<pskc:DeviceInfo>

<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>

<pskc:SerialNo>987654321</pskc:SerialNo>

<pskc:StartDate>2009-07-29Z</pskc:StartDate>

<pskc:ExpiryDate>2014-07-29Z</pskc:ExpiryDate>

</pskc:DeviceInfo>

<pskc:CryptoModuleInfo>

<pskc:Id>CM_ID_001</pskc:Id>

</pskc:CryptoModuleInfo>

<pskc:Key Id="MBK000000001" Algorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">

<pskc:Issuer>Example-Issuer</pskc:Issuer>

<pskc:AlgorithmParameters>

<pskc:ResponseFormat Length="6" Encoding="DECIMAL"/>

</pskc:AlgorithmParameters>

<pskc:Data>

<pskc:Secret>

<pskc:EncryptedValue>

<xenc:EncryptionMethod Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">

<pskc:EncryptionScheme Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>

</xenc:EncryptionMethod>

<xenc:CipherData>

<xenc:CipherValue>oTvo+S22nsmS2Z/RtcoF8Hfh+jzMe0RkiafpoDpnoZTjPYZu6V+A4aEn032yCr4f</xenc:CipherValue>

</xenc:CipherData>

</pskc:EncryptedValue>

<pskc:ValueMAC>LP6xMvjtypbfT9PdkJhBZ+D6O4w=</pskc:ValueMAC>

</pskc:Secret>

<pskc:Counter>

<pskc:PlainValue>0</pskc:PlainValue>

</pskc:Counter>

</pskc:Data>

<pskc:Policy>

<pskc:KeyUsage>OTP</pskc:KeyUsage>

</pskc:Policy>

</pskc:Key>

</pskc:KeyPackage>

</pskc:KeyContainer>

From: Pei, Mingliang [mailto:mpei at verisign.com]
Sent: Tuesday, September 08, 2009 5:59 PM
To: Philip Hoyer; Hannes.Tschofenig at gmx.net; Phillip Hallam-Baker; Salah Machani; Sean Turner
Cc: Doherty, Andrea; Magnus Nyström; KEYPROV
Subject: RE: New version of PSKC

Hi Philip,

xenc:EncryptionMethod allows <any> parameters, and the usage is xenc compliant. The usage is similar to PKCS#5 XML. Please check this example from PKCS#5 page 7: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs-5v2-0a1.pdf

<xenc:EncryptedData xmlns:pkcs-5=http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0# xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xmlns:ds=http://www.w3.org/2000/09/xmldsig# xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">

<xenc:EncryptionMethod Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">

<pkcs-5:PBES2-params>

...

In PSKC, we make the KDF parameters out of the encryption method into the common EncryptionKey element. I consider pkcs-5#pbes2 is an encryption algorithm that is clearer. If we just use aes128-cbc in the encryption method, we don't have a good place to indicate pbes2. If we miss pbes2 flag, it isn't fully compliant with PKCS#5, I think.

- Ming

From: Philip Hoyer [mailto:phoyer at actividentity.com]
Sent: Monday, September 07, 2009 6:39 AM
To: Pei, Mingliang; Hannes.Tschofenig at gmx.net; Phillip Hallam-Baker; Salah Machani; Sean Turner
Cc: Doherty, Andrea; Magnus Nyström; KEYPROV
Subject: RE: New version of PSKC

Ming,

I do not understand why the protected HOTP key value (secret) should know anything about how the key was derived.

I mean at the end the transported key is encrypted with AES-128-CBC.

So would it not be cleaner to leave all the derivation related business to the element that is under KeyContainer?

Ii would also assume that:

<pskc:Secret>

                <pskc:EncryptedValue Id="ED">
                    <xenc:EncryptionMethod
                        Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">
                        <pskc:EncryptionScheme
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>'

is NOT XMLenc standard compliant whereas:

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

Philip

From: Pei, Mingliang [mailto:mpei at verisign.com]
Sent: Wed 02/09/2009 21.48
To: Philip Hoyer; Hannes.Tschofenig at gmx.net; Phillip Hallam-Baker; Salah Machani; Sean Turner
Cc: Doherty, Andrea; Magnus Nyström; KEYPROV
Subject: RE: New version of PSKC

The reason is that DerivedKey portion only describe how a key is derived for a desired length, not indicating how a key is used. For PBES2, the encryption scheme parameter is required. It should either go to PKCS#5 parameters, or EncryptionMethod part of the xenc:EncryptedDataType. We chose the second one. The encrytion key element contains only the key portion as we have been doing, similar to the pre-shared key case. It is consistent. The common element EncryptionKey includes the key data information, not the encryption algorithm information.

- Ming

From: Philip Hoyer [mailto:phoyer at actividentity.com]
Sent: Wednesday, September 02, 2009 5:18 AM
To: Pei, Mingliang; Hannes.Tschofenig at gmx.net; Phillip Hallam-Baker; Salah Machani; Sean Turner
Cc: Doherty, Andrea; Magnus Nyström; KEYPROV
Subject: RE: New version of PSKC

Ming and all,

Please see questions and explanation of my perplexion below. Bear with me.

Which MAC key for which example?

My main concern are the PBE examples that you generated and the existing one forget for a moment the namsespace change.

Following are some differences (highlighted in bold):

SPEC ONE:

Lets start with an extract of the existing one in the spec:

    <pskc:MACMethod
        Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
        <pskc:MACKey>
            <xenc:EncryptionMethod
            Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
            <xenc:CipherData>
                <xenc:CipherValue>
2GTTnLwM3I4e5IO5FkufoNhk05y8DNyOHuSDuRZLn6DhIjoTY/dX4SkUAbQ
SWJblA7Dzi031L6FNnUrcjsGGcQ==
                </xenc:CipherValue>
            </xenc:CipherData>
        </pskc:MACKey>
    </pskc:MACMethod>

GENERATED ONE:

<pskc:MACMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">

<pskc:MACKey>

<xenc:EncryptionMethod Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">

<pskc:EncryptionScheme Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>

</xenc:EncryptionMethod>

<xenc:CipherData>

<xenc:CipherValue>2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx</xenc:CipherValue>

</xenc:CipherData>

</pskc:MACKey>

</pskc:MACMethod>

Now I do not understand why we need EncryptionScheme at all. Should it not be as the one in the spec?

I have the same question about EncryptionScheme later in both examples:

SPEC ONE:

....

<pskc:Secret>

                <pskc:EncryptedValue Id="ED">
                    <xenc:EncryptionMethod
                        Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">
                        <pskc:EncryptionScheme
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                        </xenc:EncryptionMethod>
                        <xenc:CipherData>
                            <xenc:CipherValue>
      oTvo+S22nsmS2Z/RtcoF8Hfh+jzMe0RkiafpoDpnoZTjPYZu6V+A4aEn032yCr4f
                        </xenc:CipherValue>
                    </xenc:CipherData>

GENERATED ONE:

ryptedValue>

<xenc:EncryptionMethod Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">

<pskc:EncryptionScheme Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>

</xenc:EncryptionMethod>

<xenc:CipherData>

<xenc:CipherValue>oTvo+S22nsmS2Z/RtcoF8Hfh+jzMe0RkiafpoDpnoZTjPYZu6V+A4aEn032yCr4f</xenc:CipherValue>

</xenc:CipherData>

Why do we need EncryptionScheme at all? Since we know it is a derived key in the main element?

Should these not be like the preshared key one?:

PRE-SHARED-KEY

<Secret>
                    <EncryptedValue>
                        <xenc:EncryptionMethod
            Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                        <xenc:CipherData>
                            <xenc:CipherValue>
    AAECAwQFBgcICQoLDA0OD+cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv
                            </xenc:CipherValue>
                        </xenc:CipherData>
                    </EncryptedValue>
                    <ValueMAC>aSRlEG1agUo0CS2dt/OvIAqQ6Co=
                    </ValueMAC>
                </Secret>

Also should we align the examples that they use prefixed namespace for pskc. e.g. <pskc:element> I rather have default namespace of pskc so that it reads: <element>.

Additional question, should we add the xenc11 import statement to the schema?

Philip

From: Pei, Mingliang [mailto:mpei at verisign.com]
Sent: Wed 02/09/2009 7.43
To: Philip Hoyer; Hannes.Tschofenig at gmx.net; Phillip Hallam-Baker; Salah Machani; Sean Turner
Cc: Doherty, Andrea; Magnus Nyström; KEYPROV
Subject: RE: New version of PSKC

Hi Philip,

Please see the forwarded email that includes the examples from my implementation that I sent earlier. The latest draft doesn't seem to have the CipherValue for the MAC key right. Please update it to

2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx

Thanks,

- Ming

From: Philip Hoyer [mailto:phoyer at actividentity.com]
Sent: Friday, August 28, 2009 9:56 AM
To: Hannes.Tschofenig at gmx.net; Phillip Hallam-Baker; Pei, Mingliang; Salah Machani; Sean Turner
Cc: Doherty, Andrea; Magnus Nyström; KEYPROV
Subject: New version of PSKC

Ladies and Gentlemen,

Please find attached the new version of PSKC.

Changes:

incorporated all of the feedback from Andrea and Sean.

reference name change to the new DerivedKey element (moved to XMLEnc11)

Corrected AES example to include (prepend) IV inline with XMLENC spec and mentions IV handling.

I have one big problem:

The samples that Ming sent out for PBE and RSA do not match the ones in the spec.

Especially the PBE is different form the one Ming already says was corrected.

Based on the new XML Enc 1.1 spec for PBE and DerivedKeys. Are we sure we are aligned here?

This is the only thing that needs to be clarified.

Otherwise,

What do I need to do now.

Do I just submit or send to Russ and Pasi directly?

Philip

________________________________

Philip Hoyer

Senior Architect - Office of CTO

ActivIdentity (UK)

117 Waterloo Road

London SE1 8UL

Telephone: +44 (0) 20 7960 0220

Fax: +44 (0) 20 7902 1985

Private and confidential: This message and any attachments may contain

privileged / confidential information. If you are not an intended recipient,

you must not copy, distribute, discuss or take any action in reliance on it.

If you have received this communication in error, please notify the sender

and delete this message immediately.