Subject: [secdir] SecDir review of draft-ietf-keyprov-pskc-05

From: Vincent Roca <[email-masked]>
Date: Mon, 03 May 2010 22:16:06 +0200

All,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

1- section 13: about the use of the reserved keywords...
   On many places I have the feeling that the authors are not
   sufficiently directive. Two examples (others will follow):

   * introduction: must => MUST in sentence:
"This means that special care must be taken to ensure the
confidentiality..."

   * 13.1: before the last paragraph of the first solution, add:
"Additionally, it is strongly RECOMMENDED that practical
 implementations use PBESalt and PBEIterationCount when PBE
 encryption is used."

2- section 13, about the use of the term "payload" in titles:
   After reading the introduction of section 13, I understand that
   "payload" refers to "the information contained within [a PSKC
   container]".

   However I have the feeling that the three desired security
   services are for the whole PSKC container, not only "the
   information contained within". The titles are therefore a
   little bit misleading IMHO.

3- section 13.1: rather than "one of the password-based encryption
   methods provided above", I suggest the authors add an explicit
   reference to section 6.2.

4- section 13.1: it is said:
"Different PBESalt value per key container should be used for best
protection."

   It's rather ambiguous. It's not clear to me whether it is
   recommended to use a different PBESalt for each PSKC container,
   or whether it is recommended to use a different PBESalt when a
   given PSKC container carries several keys, one PBESalt per key.

   Also: "should" => "SHOULD"

5- section 13.1:
   why isn't the IPsec/ESP not considered also as a third
   solution to provide the confidentiality, integrity and sender
   authentication services? Why do the authors only focus
   on PCKS integrated or TLS solutions? It's not clear.

6- section 13.1, last but one paragraph:
   The authors say that TLS offers extra security measures,
   especially when the digital signature does not encompass
   the entire payload. I agree, but section 13.1 is dedicated
   to confidentiality, not to integrity/authenticity verifications.
   Referring to digital signatures is meaningless in this section.

7- section 13.1, last paragraph:
   Instead of: "Validating the secure channel end-points"
   I'd rather say: "Authenticating".

8- sections 13.1, 13.2 and 13.3:
   It is mentioned on several places that TLS can be useful in
   situations where "the signature of the payload does not
   encompass the entire payload".

   Shouldn't the authors RECOMMEND that the digital signature
   encompass the whole payload instead? It would clarify...
   This is all the more true if TLS is not used, in which case
   this is strongly RECOMMENDED.

9- section 13.3: it is said:
"A weaker payload authenticity guarantee may be provided by the
 transport layer if it is configured to digest each message it
 transports."

   Why is this feature necessarily weaker? The source can be
   authenticated with the same level of security as if it was
   done by the recipient end.

Typos:

* section 13.1 (also section 3):
   Rather than saying "the portable key container", I suggest
   the authors either write everything in extenso, or use the
   PSKC acronym.

* section 6.3, first sentence: a comma is missing between
  "element information", making the sentence difficult to
  understand.

Regards,

   Vincent

---

From: "Philip Hoyer" <[email-masked]>
Date: Tue, 11 May 2010 13:19:42 +0200

Vincent,
Thanks for the review please see comments [PH] inline

-----Original Message-----
From: Vincent Roca [mailto:[email-masked]] 
Sent: Monday, May 03, 2010 9:16 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: SecDir review of draft-ietf-keyprov-pskc-05

All,

[PH] corrected

[PH] Added and corrected sentence

[PH] agreed and changed to PSKC

3- section 13.1: rather than "one of the password-based encryption
   methods provided above", I suggest the authors add an explicit
   reference to section 6.2.
[PH] added explicit reference

   Also: "should" => "SHOULD"
[PH] corrected to " A different PBESalt value per PSKC SHOULD be used
for best protection."

5- section 13.1:
   why isn't the IPsec/ESP not considered also as a third
   solution to provide the confidentiality, integrity and sender
   authentication services? Why do the authors only focus
   on PCKS integrated or TLS solutions? It's not clear.
[PH] the authors felt that the usage of the container was intended for
application level interchange of keys. Especially in online scenarios
where TLS is much more prevalent than IPSec. This does not mean that one
could not envisage use of the PSKC over IPsec and hence use IPsec
protection mechanisms. 

[PH] agreed and removed

7- section 13.1, last paragraph:
   Instead of: "Validating the secure channel end-points"
   I'd rather say: "Authenticating".
[PH] agreed and corrected 

[PH] changed text of section 13.2 "PSKC Integrity" to: " It is
RECOMMENDED that for best security	practices, the digital signature
of the container encompasses the entire PSKC."

   Why is this feature necessarily weaker? The source can be
   authenticated with the same level of security as if it was
   done by the recipient end.
[PH] it is weaker in the sense that the TLS endpoints could differ from
the key provisioning endpoints. So in that sense the signature in the
message would protect it from message sender to receiver.

Typos:

* section 13.1 (also section 3):
   Rather than saying "the portable key container", I suggest
   the authors either write everything in extenso, or use the
   PSKC acronym.
[PH] changed to PSKC besides in the first sentence of the section.

[PH] corrected

Regards,

   Vincent

---

From: Vincent Roca <[email-masked]>
Date: Mon, 17 May 2010 12:08:45 +0200

Hello Philip,

> could not envisage use of the PSKC over IPsec and hence use IPsec
[VR] I understand. Thanks for the clarification.

> message would protect it from message sender to receiver.
[VR] Said this way, I fully agree. I suggest you clarify the
I-D as well, e.g.:

"Authenticity guarantee may be provided by [...]. However, no authenticity
verification is possible once [...]. Since the TLS endpoints could 
differ from
the key provisioning endpoints, this solution is weaker than the previous
solution that relies on a digital signature of the PSKC."

Cheers,

     Vincent

---

From: "Philip Hoyer" <[email-masked]>
Date: Tue, 18 May 2010 15:17:50 +0200

Vincent,
I have changed the draft to encompass your revised wording of point 2
below.

Thanks for your help,

Philip

-----Original Message-----
From: Vincent Roca [mailto:[email-masked]] 
Sent: Monday, May 17, 2010 11:09 AM
To: Philip Hoyer
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: SecDir review of draft-ietf-keyprov-pskc-05

Hello Philip,

"Authenticity guarantee may be provided by [...]. However, no
authenticity
verification is possible once [...]. Since the TLS endpoints could 
differ from
the key provisioning endpoints, this solution is weaker than the
previous
solution that relies on a digital signature of the PSKC."

Cheers,

     Vincent