Subject: Last call comments for draft-ietf-pki4ipsec-ikecert-profile-10

From: <[email-masked]>
Date: Mon, 26 Jun 2006 15:04:53 +0300

Couple of comments about draft-ietf-pki4ipsec-ikecert-profile-10,
all fairly minor:

1) Section 3.1: "Implementations SHOULD populate ID with identity
   information that is contained within the end-entity certificate
   [...] The only case where implementations MAY populate ID with
   information that is not contained in the end-entity certificate is
   when ID contains the peer source address (a single address, not a
   subnet or range)."
  
   The part "the only case where implementations MAY [do X] is when
   [condition]" is not consistent with the RFC 2119 definition of MAY
   (or at least, it's very confusing). Is the intention to say "One
   case where implementatations MAY [do X] is when [condition]", or
   "Implementations MUST NOT [do X] unless [condition]", or possibly
   something else?

2) Section 3.1.2 (and also the same text in 3.1.3): "However,
   implementations SHOULD NOT use the DNS to map the FQDN to IP
   addresses for input into any policy decisions, unless that mapping
   is known to be secure, for example if DNSSEC [12] were employed 
   for that FQDN.

   If the FQDN in question is owned by the attacker, then even DNSSEC
   does not guarantee that the IP address is something that should be
   used as an input to policy decisions.

3) The profile contains some recommendations about CERTREQ processing
   that are not fully in line with what IKEv2 recommends.

   In particular, Section 3.3.7 says that "Implementations that
   receive CERTREQs from a peer which contain only unrecognized
   Certification Authorities SHOULD NOT continue the exchange".  
   But RFC 4306 Section 3.7 (last paragraph) seems to recommend 
   that if the contains of CERTREQ are not helpful in selecting 
   which certificate to send, its contents should be just ignored.  
 
   The latter behavior is especially sensible for IKEv2 where the
   CERTREQ contains hashes of CA public keys (instead of distinguished
   names), since the peer does not necessarily have those public
   keys at all (it doesn't need to verify its own certificate, and
   might be using other trust anchors/other methods that certificates
   to authenticate the other peer).

4) Also, Section 3.2.7 says that "When in-band exchange of certificate
   keying materials is desired, implementations MUST inform the peer
   of this by sending at least one CERTREQ.  In other words, an
   implementation which does not send any CERTREQs during an exchange
   SHOULD NOT expect to receive any CERT payloads." 
   
   It should be noted that RFC 4306 Sections 3.6 (first paragraph) and
   3.7 (first paragraph) recommend sending certificates if available,
   and suggest that CERTREQ expresses preferences about certification
   authorities (and sending one would be optional even if CERT
   payloads are needed for authentication).

5) Section 7.1: "The Contents of CERTREQ are not encrypted in IKE."
   The initiator's CERTREQ is encrypted in IKEv2 (but since it's 
   naturally sent before the initiator has authenticated the 
   responder, this helps only against passive eavesdroppers).
  
6) Throughout the document: "caseless" -> "case-insensitive"

7) References: RFCs 2314 and 2535 have been obsoleted by newer RFCs.

Best regards,
Pasi

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