Subject: [KEYPROV] Meeting Minutes of the Phone Conference from 14th June 2007

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 15 Jun 2007 21:43:17 +0200

KEYPROV Design Phone Conference:  June 14, 2007

Attendees:  

	Mingliang Pei
	Andrea Doherty
	Hannes Tschofenig
        Phillip Hallam-Baker
        Philip Hoyer

Discussion:

We went through issue 3, 4 and 5 from the issue tracker. Text has been 
incorporated into the issue tracker already and distributed to the 
mailing list.

Issue 3: Consistent definition about IDs between Keyprov and PSKC: 
TokenID, DeviceID, and KeyID
http://www.tschofenig.priv.at:8080/keyprov/issue3

The document differentiates 4 different identities: user, device, key 
id, key type
It is necessary to introduce the terms in the terminology section and to 
show how the different identities relate to each other.

Issue 4: Should TokenID and KeyID be string instead of binary?
http://www.tschofenig.priv.at:8080/keyprov/issue4

We concluded that we need to investigate closer what the impact of a 
change from base64Binary to string means for applications.

Issue 5: Different approaches used to refer to algorithms in keyprov and 
PSKC
http://www.tschofenig.priv.at:8080/keyprov/issue5

It was noticed that the usage of algorithm identification was not used 
in the same way throughout the document.
Furthermore, there is the question how to identify and register 
different algorithms. The current proposal is to use URIs and to refer 
to the XMLDSIG spec or to 4051. It might be necessary to still define a 
separate registry.

Ciao
Hannes

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

---

From: "Meyer, Ulrike" <[email-masked]>
Date: Mon, 18 Jun 2007 09:36:48 +0200

Hi Andrea, Pei, all,

here are some review comments on Section 1 of the DSKPP draft. Please excuse, if I bring up anything that has already
been discussed on the list before.

* Page 5 (Scope): what is meant by "without exposing generated, secret
material to any other entities than the server and the cryptographic
token itself" mean? In particular: doesn't the user at least in some
application scenarios have access to the content of the token? And doesn't in use case 1.3.4 the issuer get
hold of the provisioned key as well?

* Page 5 (Scope): The term "connected cryptographic tokens" should be
explained already here, e.g. by "remotely accessible". "Connected
could be misinterpreted as interconnected tokens

* Page 6 (Background, second paragraph, last sentence): "This is the strongest approach
to symmetric key provisioning, as the key  is not transported between systems, and is
therefore not vulnerable to man-in-the-middle attacks". Could be missunderstood, as man-in-the-middle attacks
can not only possible if a key itself is transported between systems, but also is any input (such as nonces, DH-parameters etc.) to a key derivation function are transported between systems. 

* Page 6 (Background): "Direct" communication should be explained more
precisely. In addition, it is a little unclear from the text which scenarios (both, the
direct and the indirect one or only one of them??) are addressed by
DSKPP

* Page 6 (Use case): An example for why a client would want to be
provisioned a symmetric key would be nice

* Page 6 (Use cases 1.3.2 and 1.3.3) these use cases sound more like
requirements then like use cases.

* Page 7 (Use case 1.3.4) In this use case: which entities are to end
up with the newly generated symmetric key? The user (in form of the
token) and the issuer? If yes, how does the issuer obtain the key from
the provisioning server? Is this covered by the protocol or not?

* Page 8 (2nd last paragraph before 1.3.8): Sentence incomplete

* Page 8 (Section 1.3.8) Last sentence does not make sense

* Page 8 (Section 1.4.8): It highly depends on the application if SMS
can provide an exceptable level of protection for the transport of
secret keys.

* Page 9 (R1): What is meant by different key types? Differnt lengths?

* Page 9 (R2 and R3): what is the difference between re-generated and
mutually generated keys??

* Page 9 (R6) What is the difference between cryptographic and
security capabilities?

* Page 9 (R7) why is this requirement not a MUST

* Page 11: The document structure section seems a little superflouse as the same information can be gathered
from the table of content

Best regards,
Uli

Dr. Ulrike Meyer
 
Nokia Siemens Networks GmbH & Co. KG
RTP NT NAS
Otto-Hahn-Ring 6
D-81730 Muenchen 
Phone: +49 89 636 41496
Fax: +49 89 636 48000
[email-masked]
 
Nokia Siemens Networks GmbH & Co. KG - Sitz der Gesellschaft/ Registered office: München (Munich) - Registergericht /Commercial register: München (Munich), HRA 88537 - WEEE-Reg.-No. DE 52984304. Persönlich haftende Gesellschafterin /General Partner: Nokia Siemens Networks Management GmbH - Geschäftsführer /Board of Directors: Christian Unterberger, Joachim Malterer, Roland Meinzer - Sitz der Gesellschaft / Registered office: München (Munich) - Registergericht /Commercial register: München (Munich), HRB 163416 ------

---

From: "CHANG Shuh" <[email-masked]>
Date: Mon, 18 Jun 2007 22:27:21 +0200

Hi All,

I have been trying to advocate the creation of a unified object model
for developing the OATH PSKC & DSKPP specs since mid last year. I think
that Issue #3 might be a good starting point for us to consider such an
OATH object model. I took the liberty to "draw up" a simple
character-based text diagram to illustrate the objects of interest.
Please see the attached text file for the proposed object model as a
starting point. If all went well, we can then consider adding the basic
character-based object model diagram in the final KeyProv spec.

Now that the PSKC needs to be "revamped" for more consistency with
DSKPP, it would be beneficial to start with a unified object model...
More detailed object model diagrams can later be generated from the
final XML schema files (please see the attached
OATH-PSKC-obj-diagrams.doc as an example for the current version of PSKC
schema.) A comparable set of object diagrams was also separately
generated from the DSKPP XML schema files... Anyway, you can see the
point.

Any thoughts/comments? Thanks.

Regards,
Shuh

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Friday, June 15, 2007 2:43 PM
> To: [email-masked]
> Subject: [KEYPROV] Meeting Minutes of the Phone Conference 
> from 14th June2007
> 
> We went through issue 3, 4 and 5 from the issue tracker. Text 
> has been incorporated into the issue tracker already and 
> distributed to the mailing list.
> 
> 
> The document differentiates 4 different identities: user, 
> device, key id, key type It is necessary to introduce the 
> terms in the terminology section and to show how the 
> different identities relate to each other.
> 
> 
> We concluded that we need to investigate closer what the 
> impact of a change from base64Binary to string means for applications.
> 
>