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

["Philip Hoyer" <[e-mail]>]

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

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

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..."

[PH] corrected

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

[PH] Added and corrected sentence


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.

[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


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"
[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. 

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.

[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 

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.

[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."


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.
[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.

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


Regards,

   Vincent