Subject: [IPsec] Questions on RFC 4945's option to skip validation

From: Scott C Moonen <[email-masked]>
Date: Tue, 13 Jan 2009 15:40:48 -0500

I'm confused about the use of RFC 4945's "option-to-skip-validation."

According to footnote [b] in the table in section 3.1, "The ID in the ID 
payload MUST match the contents of the corresponding field (listed) in the 
certificate exactly."  Earlier in section 3.1 the RFC states that "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)."  (Although 
allowing for this contradicts the MUST in footnote [b] for IP*_ADDR.)

This MUST in footnote [b] seems to make useless the 
"option-to-skip-validation" against the certificate as documented in the 
RFC.  If the above is correct, then especially in the case of FQDN and 
USER_FQDN, the "option-to-skip-validation" is not applicable, because in 
those cases the ID field MUST have been populated from the certificate 
anyway.  Yet the RFC allows for an option-to-skip-validation for these ID 
types.

My specific questions are as follows:

1) What is the use case for enabling option-to-skip-validation for FQDN 
and USER_FQDN?  Does that use case involve violating the MUST in footnote 
[b]?
2) In section 3.1, for IP*_ADDR, which of the following is correct -- the 
MUST in footnote [b], or the sentence beginning "The only case ..." a few 
paragraphs earlier?  I'm inclined to trust the MUST more since it is 
capitalized, but that outright contradicts the earlier sentence.
3) What is the use case for enabling option-to-skip-validation against the 
certificate for IP*_ADDR?  Does that use case involve violating the MUST 
in footnote [b]?
4) For IP*_ADDR, when option-to-skip-validation against the *certificate* 
is in effect, do/should we discourage the simultaneous use of 
option-to-skip-validation against the *address in the IP header*?  I.e., 
is it ever envisioned that both of these options would be exercised at the 
same time?  Disregarding the MUST in footnote [b], the earlier paragraph 
in section 3.1 seems to envision that the IP address in the ID payload 
would match the certificate or the IP header, or both, but not neither.
5) In general, is option-to-skip-validation something that would be 
discouraged for future implementations?  It is described as an 
accommodation for existing implementations.  Is it an accommodation 
because a) existing implementations may send ID payloads that don't match 
certificates, thereby violating section 3.1, or only because b) existing 
implementations offer the option to skip this check and we wanted to 
grandfather their options in, but not encourage it for future 
implementations?

I have a hunch.  I've been reading option-to-skip-validation as "I have an 
ID payload.  What do I do with the cert?"  But I wonder if it is more like 
"I have a cert.  What do I do with the ID payload?"  In other words, is 
option-to-skip-validation defined for use by implementations that want to 
use the certificate and pretty much ignore the ID payload for PAD lookup 
purposes?  For implementations that use the ID payload for PAD lookup, 
option-to-skip-validation makes little sense to me, because, in the 
language of RFC 4945, those implementations still "MUST be especially 
careful to verify the truthfulness of the [ID payload]," and the 
certificate is the right way to do that.

Thanks,

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec