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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf