[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [83.145.195.1]) 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 [127.0.0.1]) 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 other. 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). -- kivinen@iki.fi
- [IPsec] #119: Which certificate types can be mixe… Yaron Sheffer
- [IPsec] #119: Which certificate types can be mixe… Tero Kivinen
- Re: [IPsec] #119: Which certificate types can be … David Wierbowski
- Re: [IPsec] #119: Which certificate types can be … Yaron Sheffer
- Re: [IPsec] #119: Which certificate types can be … Tero Kivinen