Subject: [KEYPROV] KEYPROV Conference Call: Meeting Minutes (13th Jan. 2009)

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 13 Jan 2009 22:46:09 +0200

Participants: 

 - Ming Pei
 - Salah Machani
 - Philip Hoyer
 - Sean Turner
 - Andrea Doherty 
 - Hannes Tschofenig

Notes: 

Andrea will talk to Phillip to figure out whether he is working on the DSKPP
draft and what exactly he is editing. Andrea will also make a proposal to
the mailing list regarding ways to simplify DSKPP by this week. 

Sean will do a review of PSKC today. Sean, Ming and Andrea will review the
submitted version of PSKC this week. 

Ming produced examples for PSKC, see
http://www.ietf.org/mail-archive/web/keyprov/current/msg00572.html. Philip
will copy them into the PSKC draft. Hannes will then submit the draft today.

Open issues with the PSKC draft: 

* Which encryption algorithm has to be mandatory-to-implement, see
http://www.ietf.org/mail-archive/web/keyprov/current/msg00569.html 
Depending on the selection the examples need to be updated. 

* Ming is working on more examples. They need to be incorporated into the
document. 

* Issue raised by Anders regarding KW-AES-128: He found out that it seems to
require that the keys to be wrapped are a multiple of 8 bytes which seems to
clash with HOTP's recommended 20 byte-keys. Ming will sent a mail to Russ. 

* Working on the examples with Philip we noticed that we have a different
understanding on how extensiblity for the <Data> element would look like and
that there might be an issue. Hannes will post a mail to the list to explain
the topic. 

* Ming found one additional issue regarding the MAC algorithm and he will
post a summary to the list. 

Ciao
Hannes

_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: "Pei, Mingliang" <[email-masked]>
Date: Tue, 13 Jan 2009 17:14:14 -0800

Here is the issue that I mentioned in today's call for a resolution. It
was initially asked by Pasi. The issue is:

Currently PSKC generally assumes that the MAC key for MAC computation
for <ValueMAC> is the encryption key. It allows using a different key,
in particularly, the PBE based use cases. It is considered weak when the
same password derived key is used for both encryption and MAC
calculation. However, PSKC draft didn't specify where and how a separate
MAC can be communicated.

Proposal:

1. Similar to the encryption key specification, the entire KeyContainer
should share the same MAC key for all entries (bulk case and multiple
encrypted attribute case).
2. The MAC key information should be carried in an extended element of
the current 

    <xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType"
      minOccurs="0"/>

Note that W3C XML-DSIG has defined a way to specify MAC algorithms
including keying material. In XML-DSIG, MAC schema reuses the schema to
define signature algorithm type.

   <element name="SignatureMethod" type="ds:SignatureMethodType"/>
   <complexType name="SignatureMethodType" mixed="true">
     <sequence>
       <element name="HMACOutputLength" minOccurs="0"
type="ds:HMACOutputLengthType"/>
       <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
       <!-- (0,unbounded) elements from (1,1) external namespace -->
      </sequence>
    <attribute name="Algorithm" type="anyURI" use="required"/> 
   </complexType>

Example from XML-DSIG:

   <SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
      <HMACOutputLength>128</HMACOutputLength>
   </SignatureMethod>

The XML-DSIG definition looks fine for PSKC use as it is simple enough.
So I propose to change MACAlgorithm schema to

    <xs:element name="MACAlgorithm" type="ds:SignatureMethodType"
      minOccurs="0"/>

The KeyContainerType will become

  <xs:complexType name="KeyContainerType">
    <xs:sequence>
      <xs:element name="EncryptionKey" type="ds:KeyInfoType"
        minOccurs="0"/>
      <xs:element name="MACAlgorithm" type="ds:SignatureMethodType"
        minOccurs="0"/>
      <xs:element name="Device" type="pskc:DeviceType"
        minOccurs="1" maxOccurs="unbounded"/>
      ...
  </xs:complexType>

Examples:

A. MAC is the same as encryption key

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

B. Separate MAC key with an identifier - ds:KeyName is used

<MACAlgorithm Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
    <ds:KeyName>Example-MAC-Key1</ds:KeyName>
</MACAlgorithm>

C. Separate MAC key basing on a separate passphrase - pskc:DeriveKey is
used to carry keying material

<MACAlgorithm Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
    <DerivedKey>
      <CarriedKeyName>Example-Passphrase-For-MAC1</CarriedKeyName>
      <KeyDerivationMethod
 
Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pb
kdf2">
         <pkcs5:PBKDF2-params>
            <pkcs5:Salt>
              <pkcs5:Specified>Df3dRAhjGh8=</pkcs5:Specified>
            </pkcs5:Salt>
            <pkcs5:IterationCount>200</pkcs5:IterationCount>
            <pkcs5:KeyLength>20</pkcs5:KeyLength>
            <pkcs5:PRF/>
         </pkcs5:PBKDF2-params>
       </KeyDerivationMethod>
     </DerivedKey>
</MACAlgorithm>

Comments?

- Ming

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hannes Tschofenig
Sent: Tuesday, January 13, 2009 12:46 PM
To: [email-masked]
Subject: [KEYPROV] KEYPROV Conference Call: Meeting Minutes (13th Jan.
2009)

Participants: 

 - Ming Pei
 - Salah Machani
 - Philip Hoyer
 - Sean Turner
 - Andrea Doherty
 - Hannes Tschofenig

Notes: 

Andrea will talk to Phillip to figure out whether he is working on the
DSKPP draft and what exactly he is editing. Andrea will also make a
proposal to the mailing list regarding ways to simplify DSKPP by this
week. 

Sean will do a review of PSKC today. Sean, Ming and Andrea will review
the submitted version of PSKC this week. 

Ming produced examples for PSKC, see
http://www.ietf.org/mail-archive/web/keyprov/current/msg00572.html.
Philip will copy them into the PSKC draft. Hannes will then submit the
draft today.

* Ming is working on more examples. They need to be incorporated into
the document. 

* Issue raised by Anders regarding KW-AES-128: He found out that it
seems to require that the keys to be wrapped are a multiple of 8 bytes
which seems to clash with HOTP's recommended 20 byte-keys. Ming will
sent a mail to Russ. 

* Working on the examples with Philip we noticed that we have a
different understanding on how extensiblity for the <Data> element would
look like and that there might be an issue. Hannes will post a mail to
the list to explain the topic. 

* Ming found one additional issue regarding the MAC algorithm and he
will post a summary to the list. 

Ciao
Hannes

---

From: "Pei, Mingliang" <[email-masked]>
Date: Tue, 13 Jan 2009 17:40:05 -0800

BTW, the alternative approach is to define a type that more explicitly
defines the keying material elements in PSKC instead of the "any" type
in XML-DSIG. For example, we may define something like the following.

   <xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType"/>
   <complexType name="KeyAlgorithmType" mixed="true">
     <choice>
       <element ref="ds:KeyName" minOccurs="0"/>
       <element name="Key" type="pskc:DerivedKeyType" minOccurs="0"/>
       <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
     </choice>
    <attribute name="Algorithm" type="anyURI" use="required"/> 
   </complexType>

I preferred the xmldsig definition over this choice for reuse purpose
while the added value in a new type isn't significant.

Comments?

- Ming

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pei, Mingliang
Sent: Tuesday, January 13, 2009 5:14 PM
To: Hannes Tschofenig; [email-masked]
Subject: [KEYPROV] PSKC should be capable to support a separate
MACdifferent from encryption key --> (RE: KEYPROV ConferenceCall:
Meeting Minutes (13th Jan. 2009))

Proposal:

Example from XML-DSIG:

   <SignatureMethod

Examples:

 

Comments?

- Ming

-----Original Message-----

Participants: 

 - Ming Pei
 - Salah Machani
 - Philip Hoyer
 - Sean Turner
 - Andrea Doherty
 - Hannes Tschofenig

Notes: 

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sat, 24 Jan 2009 19:20:47 +0200

Hi Ming, 

Good that you raised this issue. It is related to a comment by Anders
recently posted to the list about computing the keyed message digest not
only over the encrypted key but to also include other information from
the PSKC document. 

I fully agree that we should re-use the mechanisms of XML-DSIG with
respect of the algorithms. However, I wonder whether we should stop
there to accomplish also what Anders raised, namely the ability to
include other XML elements and XML attributes in the calculation of the
digest. 

Section 7 of
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-01.txt shows
what I mean. The <ds:SignedInfo> element essentially describes what
information from the PSKC document is signed. We obviously do not need
<SignatureMethod> element for our purpose but the remaining elements get
pretty close (such as <Reference>, <CanonicalizationMethod>,
<DigestMethod> and <DigestValue>).  

Anders suggests a fixed set of parameters, if I understood him
correctly, that are included in the digest calculation. This is another
option; less complex but also with restricted flexibility.

Ciao
Hannes
 
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Pei, Mingliang
>Sent: 14 January, 2009 03:14
>Subject: [KEYPROV] PSKC should be capable to support a 
>separate MACdifferent from encryption key --> (RE: KEYPROV 
>ConferenceCall: Meeting Minutes (13th Jan. 2009))
>
>
>Here is the issue that I mentioned in today's call for a 
>resolution. It was initially asked by Pasi. The issue is:
>
>Currently PSKC generally assumes that the MAC key for MAC 
>computation for <ValueMAC> is the encryption key. It allows 
>using a different key, in particularly, the PBE based use 
>cases. It is considered weak when the same password derived 
>key is used for both encryption and MAC calculation. However, 
>PSKC draft didn't specify where and how a separate MAC can be 
>communicated.
>
>Proposal:
>
>1. Similar to the encryption key specification, the entire 
>KeyContainer should share the same MAC key for all entries 
>(bulk case and multiple encrypted attribute case).
>2. The MAC key information should be carried in an extended 
>element of the current 
>
>Note that W3C XML-DSIG has defined a way to specify MAC 
>algorithms including keying material. In XML-DSIG, MAC schema 
>reuses the schema to define signature algorithm type.
>
>C. Separate MAC key basing on a separate passphrase - 
>pskc:DeriveKey is used to carry keying material
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Hannes Tschofenig
>Andrea will talk to Phillip to figure out whether he is 
>working on the DSKPP draft and what exactly he is editing. 
>Andrea will also make a proposal to the mailing list regarding 
>ways to simplify DSKPP by this week. 
>
>Sean will do a review of PSKC today. Sean, Ming and Andrea 
>will review the submitted version of PSKC this week. 
>
>Philip will copy them into the PSKC draft. Hannes will then 
>submit the draft today.
>
>
>* Which encryption algorithm has to be mandatory-to-implement, 
>see http://www.ietf.org/mail-archive/web/keyprov/current/msg00569.html
>* Ming is working on more examples. They need to be 
>incorporated into the document. 
>
>* Issue raised by Anders regarding KW-AES-128: He found out 
>that it seems to require that the keys to be wrapped are a 
>multiple of 8 bytes which seems to clash with HOTP's 
>recommended 20 byte-keys. Ming will sent a mail to Russ. 
>
>* Working on the examples with Philip we noticed that we have 
>a different understanding on how extensiblity for the <Data> 
>element would look like and that there might be an issue. 
>Hannes will post a mail to the list to explain the topic. 
>
>* Ming found one additional issue regarding the MAC algorithm 
>and he will post a summary to the list. 
>
>Ciao
>Hannes
>