[IPsec] #119: Which certificate types can be mixed in one exchange?

Tero Kivinen <kivinen@iki.fi> Fri, 30 October 2009 14:11 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 199FC3A696F for <ipsec@core3.amsl.com>; Fri, 30 Oct 2009 07:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.503
X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7mUFNmyCSk1S for <ipsec@core3.amsl.com>; Fri, 30 Oct 2009 07:11:32 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi []) by core3.amsl.com (Postfix) with ESMTP id B8F563A67E9 for <ipsec@ietf.org>; Fri, 30 Oct 2009 07:11:31 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost []) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9UE6h7d007615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 16:06:43 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9UE6hk3008115; Fri, 30 Oct 2009 16:06:43 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19178.62195.841240.79258@fireball.kivinen.iki.fi>
Date: Fri, 30 Oct 2009 16:06:43 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Yaron Sheffer <yaronf@checkpoint.com>
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAB@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAB@il-ex01.ad.checkpoint.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 11 min
X-Total-Time: 10 min
Cc: IPsecme WG <ipsec@ietf.org>
Subject: [IPsec] #119: Which certificate types can be mixed in one exchange?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Oct 2009 14:11:33 -0000

Yaron Sheffer writes:
> Should be added to Sec. 3.6, probably as a new subsection.
> One Hash & URL (H&U) bundle only. Or...
> One Raw RSA key, or...
> One or more cert payloads of either type 4 or H&U (type 12)
> Can have one or more CRLs and/or OCSP content (RFC
> 4806<http://tools.ietf.org/html/rfc4806>;) added to any of the above,
> except for Raw RSA. 

I think the answer to question which types can be mixed in one
exchange is: Any.

As recipient should be able to ignore the formats it does not support
easily, and if that results to case where recipient does not have
enough information to validate the certificate then the authentication
cannot succeed. The sender should include certificates in the format
that they were requested by certificate request payload, but if it
cannot, then it might as well include the certificate in some other
format, just in case that will help the recipient. If that does not
help the recipient, then those two peers cannot authenticate each

I do not see any problem when some implementation which needs to
present certificate for peer, which didn't send any certificate
request payload, decides to send same certiface using format 11 and 4
and also provides intermediate certificates for the X.509 certificate
as hash and url of X.509 certificates and even includes CRL in format
7 if all that can be fit to the packet without causing fragmentation
(i.e. if all that fits to packet less than 1280 bytes, then there is
no reason not to include all that helpful information if that was
readily available).

Then if the initiator was very limited IPsec garage door remote
controller implementation which required public key as raw rsa key
(format 11), it can take it from there, and ignore rest, and if it
happened to be real VPN client using preper CA, it can then verify the
certificates and CRLs etc.

Limiting the number of certificate types which can be mixed in one
exchange will limit the scenarios we can use with IPsec. I.e. if we
limit there can be only one type then we need to add more
configuration to the recipient, i.e. it needs to know from somewhere
that this incoming connection is now from this limited IPsec garage
door remote controller so only raw RSA key is presented, and if it is
this VPN client (laptop) then it need to give certificates etc.

I do not think this really affects interoperability as we already have
fixed list of mandatory to implement methods, this mostly affect how
much configuration each implementation needs to fill in, compared to
using more optimistic approach that fill in everything we have and
hope the other end has enough data to finish the authentication (if we
really gave everything we had, and that was not enough for the other
end, then we clearly cannot communicate regardless what format we
would have used).