Subject: [KEYPROV] DSKPP Review

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 03 Aug 2007 15:41:36 +0200

I went through the -01 version of the DSKPP draft and I have some 
high-level document structure comments. Sorry that I haven't sent them 
earlier.

There are typically three classes of readers for these types of documents:

a) Folks that want to get an idea what the stuff is about. They don't 
want to implement it and they don't care about the details

b) Implementers; they typically look at the examples first and need also 
to understand the schema and all the encoding details. They do often not 
really worry about the underlying security properties -- they assume 
everything is fine.

c) Crypto-guys; they don't care about implementation details but focus 
on the abstract message interaction, the security consideration section 
and the key derivation procedures

For (a) the document already does a pretty good job. Readers might find 
interesting content in Section 1, 3 and the first parts of Section 4.

For (b) we could do better. There is a lot of text in there that is 
pretty hard to follow although it is (theoretically) pretty simple.
The document will (in my view) be much simpler to read if we restructure 
Section 4 (DSKPP), Section 4.9 (Schema Basics), and

Section 4.10 (DSKPP Messages) according to the different variants of 
DSKPP and explain each one-by-one instead of distributing the content 
over multiple sections. I also believe that we should not provide 
snippets of the XML schema anywhere (e.g., Section 4.9) since it does 
not add a lot of value for the reader. If someone cares about the schema 
then they will look at it. What is more interesting are examples since 
they explain the concepts pretty nicely.

An example structure of a recently written protocol can be found with LoST:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-05.txt

For the LoST document we got a number of reviews, pretty good comments 
and readers found it easy to follow.

Btw, do we expect that all clients and all servers will implement all 
variants of DSKPP (One-Pass, Two-Pass and Four-Pass protocol exchange)?

For (c) I also believe that we need to provide the reader more 
information. I am missing the abstract description of the protocol.

Section 4.2 provides some information in textual form but we might want 
to utilize the terminology we introduced in Section 2 to either 
represent the protocol in a form that is similar to Section 3 of 
http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-06.txt or to 
use a Alice-and-Bob notation as it is often used as a basis for a 
subsequent formal verficiation. In any case, the representation allows 
to focus on the elements that are important for the security analysis 
and ignores all XML details.

The key derivation description should also be the same on the client and 
on the server. Figure 4 should essentially be replaced by something that 
is closer to Figure 2 of 
http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-06.txt.

Since the three protocol variants are from a security point of view 
totally different protocols I suggest to treat them separately in the 
security consideration section as well.

Acknowledgements: The section is really short given that a number of 
people provided review comments. As an example, LoST 
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-05.txt is 
somewhat verbose on listing what individuals contributed. I do, however, 
think it is a good idea to be a bit more explicit. Some people spend a 
considerable amount of time on reviews and on providing input and we 
should have enough time to thank them in the document. The typical rule 
is: If someone participates in discussions and does reviews then he will 
be listed in the acknowledgment section. If a person provides text he 
will be listed in the contributors section.

Section 9: Intelluctual Property Considerations. Do you think that this 
section is needed? Isn't almost every company name a trademark?

So, a high-level ToC might look as follows:

1. Introduction
2. Terminology
3. Use Cases

[Use short abbreviations for the subsection heading rather than an 
entire sentence.
For example, instead of saying "A cryptographic module renews its 
symmetric key with the same key ID" use a subject heading

like "Key Renewal" or "Rekeying"]

4. DSKPP Overview

[The high-level description on the message flows and information about 
the information that is exchanged in the different variants goes in here.

A later subsection also contains the key derivations and mac calculations.
I would omit the key container format here and the server authentication 
section did not say a lot. The client authentication section is fine 
when put in context of the different variants.

Essentially, this is a clean-up of the existing Section 
4.1,4.2,4.3,4.4.,4.5,4.6,4.7,4.8.
]

5. Four-Pass Protocol

[The entire description of the 4 pass protocol goes in here with a focus 
on the XML stuff. This section includes XML examples. You might want to 
highlight the messages rather than specific types, such as 
AbstractRequestType, since they are not that important. Start with a 
very simple example and explain what is in there and then extend it so 
that people understand the additional functionality.

These sections also need to provide enough information to visualize the 
state machine without necessarily drawing state machines. Someone you 
need to describe the different errors and warnings. You can either 
attach them to the individual variants or put them into a separate 
section if they are applicable to all three protocol variants.]

6. Two-Pass Protocol

[Same as above but for the 2 pass protocol.]

7. One-Pass Protocol

[Same as above but for the 1 pass protocol.]

[Section 5,6,&7 should be done in reverse order depending what is easier 
to explain. Additionally, it might be possible and

useful to separate a few things that are common for all three variants 
and to put them on the top.]

8. Trigger Message

9. Extensiblity

[Talk about how to extend the protocol. This is not necessarily Section 
4.11 since I couldn't understand Section 4.11]

10. HTTP Protocol Binding

11. Schema

12. IANA Considerations

13. Security Considerations

13.1 One-Pass Protocol
13.2 Two-Pass Protocol
13.3 Four-Pass Protocol

14. Acknowledgements

15. References

More comments on the details later when someone thinks that this 
document restructuring is a good idea.

Ciao
Hannes

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

---

From: "Doherty, Andrea" <[email-masked]>
Date: Fri, 3 Aug 2007 10:19:04 -0400

Hannes,
I think this is great feedback and agree with the document restructuring proposal.
Andrea

________________________________

From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Fri 8/3/2007 9:41 AM
To: [email-masked]
Subject: [KEYPROV] DSKPP Review

1. Introduction
2. Terminology
3. Use Cases

4. DSKPP Overview

5. Four-Pass Protocol

6. Two-Pass Protocol

7. One-Pass Protocol

8. Trigger Message

9. Extensiblity

11. Schema

12. IANA Considerations

13.1 One-Pass Protocol
13.2 Two-Pass Protocol
13.3 Four-Pass Protocol

14. Acknowledgements

15. References

Ciao
Hannes

---

From: "Pei, Mingliang" <[email-masked]>
Date: Fri, 3 Aug 2007 09:36:56 -0700

I like the suggestions too. Thanks, - Ming 

-----Original Message-----
From: Doherty, Andrea [mailto:[email-masked]] 
Sent: Friday, August 03, 2007 7:19 AM
To: Hannes Tschofenig; [email-masked]
Subject: RE: [KEYPROV] DSKPP Review

Hannes,
I think this is great feedback and agree with the document restructuring
proposal.
Andrea

There are typically three classes of readers for these types of
documents:

An example structure of a recently written protocol can be found with
LoST:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-05.txt

1. Introduction
2. Terminology
3. Use Cases

4. DSKPP Overview

[The high-level description on the message flows and information about
the information that is exchanged in the different variants goes in
here.

A later subsection also contains the key derivations and mac
calculations.
I would omit the key container format here and the server authentication
section did not say a lot. The client authentication section is fine
when put in context of the different variants.

5. Four-Pass Protocol

6. Two-Pass Protocol

7. One-Pass Protocol

8. Trigger Message

9. Extensiblity

11. Schema

12. IANA Considerations

13.1 One-Pass Protocol
13.2 Two-Pass Protocol
13.3 Four-Pass Protocol

14. Acknowledgements

15. References

Ciao
Hannes