Subject: [KEYPROV] Issue Tracker Up and Running

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 07 Jun 2007 22:27:04 +0200

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

---

From: "CHANG Shuh" <[email-masked]>
Date: Wed, 13 Jun 2007 23:18:51 +0200

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,
> 
> 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>
> * Consistent definition about IDs between Keyprov and PSKC: 
> TokenID, DeviceID, and KeyID <issue3>
> * Change element names to reflect keyprov and request / 
> response style <issue1>
> * Document the relationship between 
> SupportedKeyInitializationMethod and EncryptionMethod in a 
> response message <issue9>
> * 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
>  
>

---

From: "Doherty, Andrea" <[email-masked]>
Date: Thu, 14 Jun 2007 12:30:52 -0400

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,

Thanks.

Best Regards,
Shuh Chang
Senior Systems Architect

---

From: "Doherty, Andrea" <[email-masked]>
Date: Thu, 14 Jun 2007 14:40:49 -0400

Hi Ming,
Thanks for reviewing the draft, and for your contributions to the
schema, examples, etc.  I'll look carefully at your comments and respond
to them within the next few days.
Andrea

-----Original Message-----
From: Pei, Mingliang [mailto:[email-masked]] 
Sent: Thursday, June 14, 2007 1:39 PM
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,

-----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,

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.

Thanks.

Best Regards,
Shuh Chang
Senior Systems Architect

> * 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>

> SupportedKeyInitializationMethod and EncryptionMethod in a response 
> message <issue9>