Subject: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED question

From: David Wierbowski <[email-masked]>
Date: Fri, 22 May 2009 09:30:24 -0400

If I do not send an HTTP_CERT_LOOKUP_SUPPORTED notify is it valid for my
peer to send me a certificate payload with a hash and URL encoding (i.e. 12
or 13)?  I do not see any language in RFC 4306 or 4945 that states the peer
MUST NOT send a certificate payload with a hash and URL encoding in this
case.

Dave Wierbowski

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 22 May 2009 08:25:07 -0700

At 9:30 AM -0400 5/22/09, David Wierbowski wrote:
>If I do not send an HTTP_CERT_LOOKUP_SUPPORTED notify is it valid for my peer to send me a certificate payload with a hash and URL encoding (i.e. 12 or 13)? I do not see any language in RFC 4306 or 4945 that states the peer MUST NOT send a certificate payload with a hash and URL encoding in this case.

It is definitely valid to send those payloads regardless of the notify.

--Paul Hoffman, Director
--VPN Consortium

---

From: David Wierbowski <[email-masked]>
Date: Fri, 22 May 2009 11:52:03 -0400

Why?

Dave Wierbowski

z/OS Comm Server Developer

 Phone:
    Tie line:   620-4055
    External:  607-429-4055

             Paul Hoffman                                                  
             <paul.hoffman@vpn                                             
             c.org>                                                     To 
             Sent by:                  David                               
             ipsec-bounces@iet         Wierbowski/Endicott/IBM@IBMUS,      
             f.org                     [email-masked]                      
                                                                        cc 
                                                                           
             05/22/2009 11:25                                      Subject 
             AM                        Re: [IPsec]                         
                                       HTTP_CERT_LOOKUP_SUPPORTED question 

                                                                           

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 22 May 2009 08:57:29 -0700

>Why?

Because there is nothing in the document to indicate that it is invalid. HTTP_CERT_LOOKUP_SUPPORTED is only mentioned twice in RFC 4306:

   Certificate payloads SHOULD be included in an exchange if
   certificates are available to the sender unless the peer has
   indicated an ability to retrieve this information from elsewhere
   using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.

. . .

        HTTP_CERT_LOOKUP_SUPPORTED               16392

            This notification MAY be included in any message that can
            include a CERTREQ payload and indicates that the sender is
            capable of looking up certificates based on an HTTP-based
            URL (and hence presumably would prefer to receive
            certificate specifications in that format).

Neither of those make it sound like it is required before sending type 12 or 13 certificates.

--Paul Hoffman, Director
--VPN Consortium

---

From: David Wierbowski <[email-masked]>
Date: Fri, 22 May 2009 12:08:20 -0400

Paul,

Thanks, but now I'm confused by an answer Tero provided to a slightly
different question back in July of 2007 (subject [Ipsec] Comments on
draft-hoffman-ikev2bis-01.txt).  From Tero's answer I had expected to see
something that would disallow using those encoding types if you did not
receive the HTTP_CERT_LOOKUP_SUPPORTED.  See below.

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

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

> 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?

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.

Dave Wierbowski

 Phone:
    Tie line:   620-4055
    External:  607-429-4055

             Paul Hoffman                                                  
             <paul.hoffman@vpn                                             
             c.org>                                                     To 
             Sent by:                  David Wierbowski/Endicott/IBM@IBMUS 
             ipsec-bounces@iet                                          cc 
             f.org                     [email-masked],                     
                                       [email-masked]              
                                                                   Subject 
             05/22/2009 11:57          Re: [IPsec]                         
             AM                        HTTP_CERT_LOOKUP_SUPPORTED question 

                                                                           

>Why?

Because there is nothing in the document to indicate that it is invalid.
HTTP_CERT_LOOKUP_SUPPORTED is only mentioned twice in RFC 4306:

. . .

Neither of those make it sound like it is required before sending type 12
or 13 certificates.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 22 May 2009 11:04:23 -0700

At 12:08 PM -0400 5/22/09, David Wierbowski wrote:
>Paul,
>
>Thanks, but now I'm confused by an answer Tero provided to a slightly different question back in July of 2007 (subject [Ipsec] Comments on draft-hoffman-ikev2bis-01.txt). From Tero's answer I had expected to see something that would disallow using those encoding types if you did not receive the HTTP_CERT_LOOKUP_SUPPORTED. See below.

I cannot speak for Tero. I can only say what is in the RFC and the current draft. Did either of the quotes I sent make it sound like one could not sent hash-and-URL if HTTP_CERT_LOOKUP_SUPPORTED was not received?

>other end is CONFIGURED to allow HTTP lookups for the certificates.

While that is true, a peer is not required to send it if that peer is configured to allow HTTP lookups.

--Paul Hoffman, Director
--VPN Consortium

---

From: David Wierbowski <[email-masked]>
Date: Fri, 22 May 2009 16:39:18 -0400

Did I say either of the quotes you sent make it sound like one could not
sent hash-and-URL if HTTP_CERT_LOOKUP_SUPPORTED was not received?

I said I'm confused by Tero's previous answer which makes it sound as if
such a restriction is implied.

I guess the value in the HTTP_CERT_LOOKUP_SUPPORTED notify is  that you
know when it is safe to use the hash and URL encoding, but it also allows
you to send the hash and URL encoding to a peer that may have disabled that
support via a configuration option.  That doesn't seem like a good design
to me, but it's certainly flexible :>).

Dave Wierbowski

             Paul Hoffman                                                  
             <paul.hoffman@vpn                                             
             c.org>                                                     To 
             Sent by:                  David Wierbowski/Endicott/IBM@IBMUS 
             ipsec-bounces@iet                                          cc 
             f.org                     [email-masked],                     
                                       [email-masked]              
                                                                   Subject 
             05/22/2009 02:04          Re: [IPsec]                         
             PM                        HTTP_CERT_LOOKUP_SUPPORTED question 

                                                                           

I cannot speak for Tero. I can only say what is in the RFC and the current
draft. Did either of the quotes I sent make it sound like one could not
sent hash-and-URL if HTTP_CERT_LOOKUP_SUPPORTED was not received?

>other end is CONFIGURED to allow HTTP lookups for the certificates.

While that is true, a peer is not required to send it if that peer is
configured to allow HTTP lookups.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 22 May 2009 15:47:39 -0700

At 4:39 PM -0400 5/22/09, David Wierbowski wrote:
>Did I say either of the quotes you sent make it sound like one could not sent hash-and-URL if HTTP_CERT_LOOKUP_SUPPORTED was not received?

Sorry, I took it as implied.

>I said I'm confused by Tero's previous answer which makes it sound as if such a restriction is implied.

I actually don't even take that from Tero's response, but he wasn't clear either way.

>I guess the value in the HTTP_CERT_LOOKUP_SUPPORTED notify is that you know when it is safe to use the hash and URL encoding

Yep.

>, but it also allows you to send the hash and URL encoding to a peer that may have disabled that support via a configuration option.

Yep.

> That doesn't seem like a good design to me, but it's certainly flexible :>).

Much of IKEv1 and IKEv2 are not "good design" because of too much flexibility, but the alternative is being too restrictives for many environments.

--Paul Hoffman, Director
--VPN Consortium