Subject: [KEYPROV] FW: Some comments about DSKPP draft

From: "Pei, Mingliang" <[email-masked]>
Date: Thu, 14 Jun 2007 23:51:09 -0700

Posting my earlier comment to this list. - Ming

-----Original Message-----
From: Pei, Mingliang 
Sent: Thursday, June 14, 2007 10:39 AM
To: 'Doherty, Andrea'
Cc: Hallam-Baker, Phillip; 'KEYPROV Roundup Issue Tracker'; Salah
Machani
Subject: Some comments about DSKPP draft

Hi Andrea,

Thank you for the DSKPP draft. It is 94 pages; you have put a huge
effort there. 

Here are a few comments from my initial read of DSKPP while I am still
reviewing some more sections.

1. Section 3.3: 

Make it more explicit that OTP secret is derived from client and server
mutual contribution, and OTP secret is purely server's reply in two pass
case. This was said in the beginning of the doc, but somehow didn't
appear very obvious when 2 pass is described.

Suggest to add a section 3.3.4 or 3.4 to provide a best practice section
about when each one should be used.

2. Section 3.7: it looks like that it implies to all passes. We should
label it under 4 pass section.

Suggest to have a section particular about 4 pass and client
participated key derivation there. This section can then have current
3.6 - 3.8 as sub-sections which applies only to 4 pass case.

3. Key confirmation section 3.9: the SecretContainer will have a MAC
that confirms key correctness upon decryption. The additional
confirmation is redundant, right? 

Do you feel that we can leave out the key confirmation in two pass case?

At least, we need to merge both. This seems to be an issue that we can
add to the Issue Tracker.

4. Section 3.9.2: Our sample ClientHello message doesn't give a nonce R,
which is considered the main scenario for 2 pass.

5. HTTP hearder issue as we have described in Issue Tracker

6. Unsupported <xenc> is used in PSKC container of Sample ServerFinished
for two pass:

<xenc:CipherData> is used in Value element of a Secret in PSKC
SecretContainer, which isn't PSKC spec.

           <Data Name="SECRET">
             <Value>
               <xenc:CipherData>
               7JHUyp3azOkqJENSsh6b2vxXzwGBYypzJxEr+ikQAa229KV/BgZhGA==
               </xenc:CipherData>
             </Value>
           </Data>

While the value can be any thing, include further XML data, this may
have an inter-op issue about what value to expect for a secret. In our
PSKC example, we assume the value is encrypted value with the key
specified in top of the SecretContainer.

Thank you,

- Ming

-----Original Message-----
From: Doherty, Andrea [mailto:[email-masked]]
Sent: Thursday, June 14, 2007 9:31 AM
To: CHANG Shuh; Pei, Mingliang
Cc: Hannes Tschofenig; [email-masked]
Subject: RE: [KEYPROV] Issue Tracker Up and Running

Shuh,
With respect to item 3, below, you are correct that there is a typo, and
this was corrected in the schema included in
draft-doherty-keyprov-dskpp-00.txt.

I agree with your recommendations in #1 and #2 below.  Do others also
agree?
Andrea

-----Original Message-----
From: CHANG Shuh [mailto:[email-masked]]
Sent: Wednesday, June 13, 2007 5:19 PM
To: Doherty, Andrea; Pei, Mingliang
Cc: Hannes Tschofenig; [email-masked]
Subject: RE: [KEYPROV] Issue Tracker Up and Running

Hi Andrea & Ming,

I had a chance to go over the recently merged KeyProv XML schema
"KEYPROV Draft 05-23-2007.xsd" and have a few minor suggestions.

1. Change the name KeyType (in ServerHelloPDU) to KeyAlgorithm so that
it's more consistent with the other elements such as EncryptionAlgorithm
and MacAlgorithm:

Change to this ===>    <xs:element name="KeyAlgorithm"
type="AlgorithmType"/>
                    <xs:element name="EncryptionAlgorithm"
type="AlgorithmType"/>
                    <xs:element name="MacAlgorithm"
type="AlgorithmType"/>
                    <xs:element name="EncryptionKey"
type="ds:KeyInfoType"/>

The current declaration of
          <xs:element name="KeyType" type="AlgorithmType"/> might look a
bit confusing in the concatenated word "Type" for the element name. It's
better to just use concatenated "Type" for type name like the rest.

2. Same change with SupportedKeyTypes (in ClientHelloPDU) to
SupportedKeyAlgorithms for the same reason.

3. There seems to be a typo in SampleClientHelloTwoPass.xml file. Should
the following line:
===>            <ds:KeyName>Key-001></ds:KeyName>
be changed to: 
                    <ds:KeyName>Key-001</ds:KeyName>

Note the trailing ">" character at the end of "Key-001" KeyName in the
current file.

Thanks.

Best Regards,
Shuh Chang
Senior Systems Architect
Security, Network Identity
Gemalto
Tel: +1 512-257-3859
Fax: +1 512-257-3904
8311 North FM 620 Road
Austin, Texas 78726-4001
[email-masked]
www.gemalto.com

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Thursday, June 07, 2007 3:27 PM
> To: [email-masked]
> Subject: [KEYPROV] Issue Tracker Up and Running
> 
> Hi all,
> 
> we have installed an issue tracker (see
> http://www.tschofenig.priv.at:8080/keyprov/index) and Ming has added 14 
> issues, namely:
> 
> * Shall we send authentication ID in a separate field or the same 
> value in part of authentication value? <issue14>
> * Shall we explicitly document how to construct AuthenticationCode 
> over HTTP case? <issue13>
> * Should we use strongly typed message or any type for flexibility? 
> <issue12>
> * How to refer to HOTP and SecurID OTP algorithms? <issue8>
> * Should TokenID and KeyID be string instead of binary? <issue4>
> * Consistent definition about IDs between Keyprov and PSKC: 
> TokenID, DeviceID, and KeyID <issue3>
> * Register PSKC container URI and refer to this in keyprov spec 
> <issue2>
> * Change element names to reflect keyprov and request / response style

> <issue1>
> * Is special keyprov HTTP header definition required? <issue11>
> * Do we need to provide SOAP binding and where if so? <issue10>
> * Document the relationship between
> SupportedKeyInitializationMethod and EncryptionMethod in a response 
> message <issue9>
> * Shall we support an option for other response channel such as SMS? 
> <issue7>
> * Refer to EncryptionAlgorithm from ClientHello for the 
> SupportedEncryptionAlgorithms? <issue6>
> * Different approaches used to refer to algorithms in keyprov and PSKC

> <issue5>
> 
> Btw, I linked the issue tracker with the KEYPROV mailing list (as you 
> have seen from the previous message to the list).
> 
> Ciao
> Hannes
>  
> 
> _______________________________________________
> KEYPROV mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/keyprov
> 

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