Subject: [IPsec] Hash & URL for certificates

From: Yoav Nir <[email-masked]>
Date: Fri, 26 Sep 2008 00:13:23 +0300

Hi.

I know what I'm proposing below is a protocol change, but I'm going to  
propose it anyway.

Section 3.6 (Certificate Payload) of the bis document says the  
following:
> 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
> two Hash and URL formats (with HTTP URLs).  Implementations SHOULD be
> capable of being configured to send and accept Raw RSA keys.  If
> multiple certificates are sent, the first certificate MUST contain
> the public key used to sign the AUTH payload.  The other certificates
> may be sent in any order.
Frankly, I hate this entire paragraph, because it mandates  
configuration abilities for implementations. It should be perfectly  
fine to have specialized implementations that, for example, are remote- 
access clients that do not support sending certificates at all.
To allow so-called "minimal" implementations we do not mandate support  
for Create_Child_SA and rekeying, we do not mandate support for NAT-T,  
CFG or EAP, or for window sizes greater than 1.
And yet here we are mandating that every compliant implementation  
support chains of 4 certificates. But the really bad part is that  
every implementation MUST be capable of being configured to send and  
accept the two Hash&URL formats. That means that every IKEv2  
implementation MUST have an HTTP client (to fetch the certs).  
Implementations without support for the Hash&URL format are not  
compliant.
I know there are several implementations that do not support this,  
mine included. Since implementations currently "MUST be capable of  
being configured..." but not "MUST be configured..." it's entirely  
possible that a particular peer will not support Hash&URL, so what I  
propose will not harm interoperability.
I suggest that at least this requirement be demoted to MAY or SHOULD.  
IMO Hash&URL is a specialty feature that's appropriate for some  
environments but not others. There is an illuminated discussion about  
a similar extension to TLS going on right now on the TLS mailing list.
While we're at it, I suggest demoting the 4-certificate requirement to  
a SHOULD as far as sending is concerned. 
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 26 Sep 2008 08:21:52 +0300

Hi Yoav,

In my reading, "MUST be capable of being configured" is exactly the same as
"MUST implement", which is what we specify in RFCs. It's just a white box
way of ensuring it, vs. the black box "reverse engineer the code to find out
if the feature is really there". So I have no problem with this wording.

I dislike the Hash-and-URL mechanism myself, it has the potential to add
countless security vulnerabilities to an IPsec implementation.

But I am strongly opposed to your proposal. The text you are quoting appears
in RFC 4306, and we must not (MUST NOT) use the work on bis as an excuse to
open up design decisions that we made in 4306. Both for the pragmatic reason
that everybody has their own set of favorite changes (which they view as
"corrections") to the spec, and this debate could drag on for years; and
also because the industry needs a stable specification for a while, as IKEv2
implementations are starting to emerge.

Thanks,
	Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yoav Nir
Sent: Friday, September 26, 2008 0:13
To: [email-masked]
Subject: [IPsec] Hash & URL for certificates

Hi.

Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Fri, 26 Sep 2008 11:27:14 +0300

I'm afraid it's going to make most products non-compliant.

There are library implementations out there with Hash&URL: strongSwan,  
openIKEv2, probably others.

But a library is not the same as an implementation. Sure you can just  
run strongSwan as is, and configure it using large text files in the / 
etc directory, but that is not the usual way IPsec is used.

You usually have a product that packages a library (open or closed  
source) with a user interface. This feature is so obscure, that I  
believe many vendors (open-source user interfaces tend to suffer from  
the design-by-committee syndrome that means all the text file features  
are there) will omit Hash&URL and end up with non-compliant products.  
Demoting the MUST to SHOULD allows them to not support Hash&URL if  
there's a good reason, such as "our users don't have web servers to  
store their certificates on."

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 26 Sep 2008 14:00:55 +0300

Yoav Nir writes:
> support chains of 4 certificates.

PKIX Certificates are already MUST in section 4. The text saying you
"MUST be capable of being configured to send and accept up to four
X.509 certificates in support of authentication" does NOT necessarely
mean you have to support full chains in your certificates libraries.
If It would want to say you MUST support certificate chains up to 4
certificates it would say so. 

It would be quite ok for your implementation to be manually configured
to check that it gets certificate which has the public key mathing the
public key given in configuration for the remote end and accept and
ignore the other certificates sent by the other end. I.e. it could use
the first certificate as Raw RSA key and compare that Raw RSA against
its configuration.

Again, same implementation could be configured to send up to 4
certificates out, and not bother about what they really mean. 

> But the really bad part is that every implementation MUST be capable
> of being configured to send and accept the two Hash&URL formats.
> That means that every IKEv2 implementation MUST have an HTTP client
> (to fetch the certs).

Again, there is no requirement for actually adding http-client or
server to either end. The URL pointing to the certificate can also
point to some external server (for example web-server provided by CA).
Again the certificate can be preconfigured to the system in minimal
implementations, i.e. it can just verify that the hash given in the
ash and url must match the one preconfigured in to the system.

It must be configured to send the hash&URL of its own certificate so
if the other end has full implementation it can fetch the certificate
(if it does not already have it) from the external http-server. Also
it must be able to accept incoming hash&URL so it can check if hash
matches the certificates it already hash. There is no requirement for
it to actually being able to fetch the certificates using HTTP (i.e.
if it does not send HTTP_CERT_LOOKUP_SUPPORTED then it does not
support fetching certificates over http). 

> Implementations without support for the Hash&URL format are not  

True, so such implementations should add support for them to be
compliant. 

> propose will not harm interoperability.

The reason for that requirement is that should have implementations
that can be configured to work with certificates which are too large
to be sent inside the IKE because of the fragmentation issues. In
those cases by sending only hash of the certificate we can reduce the
size of the packet. It is up to the implementations whether they
actually use the URL to fecth the certificate, or if they use some
other methods (LDAP, preconfigured certificates, CA specific
certificate retrieval protocol) to fetch the certificate. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec