Subject: [Ipsec] Comments on draft-hoffman-ikev2bis-01.txt

From: Keith Welter <[email-masked]>
Date: Wed, 18 Jul 2007 13:17:41 -0700

Section 3.6
The existence of the HTTP_CERT_LOOKUP_SUPPORTED notification suggests that 
the support is optional.  However, the following statement seems to 
suggest otherwise:
   Implementations MUST be capable of being configured to send and
   accept up to four X.509 certificates in support of authentication,
   and also MUST be capable of being configured to send and accept the
   first two Hash and URL formats (with HTTP URLs).

Nit: Why say "first two Hash and URL formats"?  There are only two Hash 
and URL formats defined.  Including the type values (12 and 13) would 
eliminate any ambiguity.

Since an implementation MUST be capable of being configured to send and 
accept the first two Hash and URL formats it's seems to follow that an 
implementation also MUST support HTTP certificate lookup (making the 
HTTP_CERT_LOOKUP_SUPPORTED notification extraneous).  I believe the intent 
is for HTTP certificate lookup support to be optional but a clarification 
to that effect would be helpful.

Assuming HTTP certificate lookup support is optional, how should an 
implementation handle receipt of a CERT payload containing either of the 
Hash and URL formats (or any other unsupported encoding)?  Presumably the 
implementation should ignore the certificate payload in this case.  Is 
that correct?

Nit: There is a typo "syntax is for some" in the following text. 
   Specific syntax is for some of the certificate type codes above is
   not defined in this document.  The types whose syntax is defined in
   this document are:

Section 3.7
Is it safe to assume that a CERTREQ Certificate Encoding value of 12 or 13 
implies the same thing as HTTP_CERT_LOOKUP_SUPPORTED?  If so, the 
HTTP_CERT_LOOKUP_SUPPORTED notification would seem to be extraneous. 
Clarification on this point would be helpful.

There is a lower-case "must" in the following sentence:
   Certificate revocation checking must be considered during the
   chaining process used to select a certificate.

Is this "must" to be interpreted differently than an upper-case MUST?

This section seems to imply that it is not a protocol error for an 
exchange to contain 1 or more CERTREQ payloads but zero CERT payloads. 
Conversely, it seems that it is not a protocol error for an exchange to 
contain zero CERTREQ payloads but 1 or more CERT payloads.  Is this 
correct?

Thanks,

Keith Welter
Enterprise Networking Solutions
1-415-545-2694 (T/L: 473-2694)
_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Jul 2007 17:05:52 +0300

> to that effect would be helpful.

HTTP_CERT_LOOKUP_SUPPORTED is not extraneous, as it tells whether the
other end is CONFIGURED to allow HTTP lookups for the certificates.

> implementation should ignore the certificate payload in this case.  Is 

If you receive certificate payload you cannot process you can ignore
it and try to see if you can still authenticate the other end. If you
happen to have the certificate for the other end for some other reason
(preconfiguration, cached by previous session etc) then you can
authenticate the other end, if you do not have the certificate you
will fail the authentication. 

> Clarification on this point would be helpful.

I would say that if you request certificates in hash and url format
then in that case HTTP_CERT_LOOKUP_SUPPORTED might have been left out,
but on the other hand if you request certificates as normal X.509
certificates, and send HTTP_CERT_LOOKUP_SUPPORTED then the other end
can send certificates either inline or as hash and url format, and in
that case the HTTP_CERT_LOOKUP_SUPPORTED is not extraneous. 

> Is this "must" to be interpreted differently than an upper-case MUST?

I think that when you follow the normative reference to the base
certificate document, it is explicitly said there that certificate
revocation checking is MUST.

> contain zero CERTREQ payloads but 1 or more CERT payloads.  Is this 

Yes. For example in the common VPN case the laptop client (initiator)
might be preconfigured to have the certificate of the SGW to be used.
In that case the initiator will only send CERT payload for his own
certificate, but does not request any certificates as he already has
certificate for the other end. And the SGW end will simply send his
CERTREQ to request the certificate from the laptop, but as SGW already
knows laptop client is preconfigured to have his certificate (and the
laptop didn't ask it with CERTREQ) he does not send his CERT at all. 
-- 
[email-masked]