From ipsec-bounces@ietf.org Wed Mar 01 02:51:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEM5z-00054F-0p; Wed, 01 Mar 2006 02:50:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEM5y-00054A-7Y for ipsec@ietf.org; Wed, 01 Mar 2006 02:50:02 -0500 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEM5w-0001s7-Iz for ipsec@ietf.org; Wed, 01 Mar 2006 02:50:02 -0500 Received: from [194.29.46.41] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k217nnaw013426; Wed, 1 Mar 2006 09:49:49 +0200 (IST) Message-ID: <4405521D.7080601@checkpoint.com> Date: Wed, 01 Mar 2006 09:49:49 +0200 From: Yoav Nir Organization: Check Point User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: =?GB2312?B?IrbFtLrR4ChEVSBDaHVuLXlhbiki?= <210313041@suda.edu.cn> Subject: Re: [Ipsec] each side uses different authentication method? References: <20060301013239.88CC86CA09@proxy3.suda.edu.cn> In-Reply-To: <20060301013239.88CC86CA09@proxy3.suda.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by michael.checkpoint.com id k217nnaw013426 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "ipsec@ietf.org" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org It means that one side (call it A) presents a certificate and signs with the private key, while the other side (call it B) does not present a certificate and signs with the shared secret. At the ICSA bake-off we called this "hybrid mode". IMO it does not make sense at all. To get this done, you need to have all of the following: 1. B has no certificate, but trusts the CA. 2. There is a shared secret that is so good, that A trusts that anyone who has it, must be B. If condition #2 holds, why do they need PKI? They can use the shared secret. If it doesn't, how can A know that B is indeed B? >From a pure security POV, this only makes sense if A trusts that only B (and A) know the shared secret, but B does not. B needs to see a certificate to believe that A is really A. I just don't think this is a real-world scenario. So why did they put this in? I think it has more to do with psychology than security. There is a general feeling among vendors that PKI is very hard to implement, because of difficulty in distributing and storing the certificates, especially to clients. So the client should authenticate with a shared secret (or EAP). This is not a recommended practice since it's open to dictionary attacks, but people still do it. The user remembers the shared secret, so in their mind, it will never be compromised on their end. The gateway, on the other hand, may have backups, or other gateways centrally managed and having the same shared secret. Having the gateway authenticate with a certificate gives users that warm and fuzzy feeling that this is indeed the gateway. Psychologically, people think of the shared secret as belonging to the user, so it's not a good way to authenticate the gateway. =B6=C5=B4=BA=D1=E0(DU Chun-yan) wrote: > Hi, > > In section 2.15 of RFC4306=A3=AC"There is no requirment that the initia= tor and responder sign with the same cryptographic algorithms.""In partic= ular, the initiator may be using a shared key while the responder may hav= e a public signature key and certificate." > How could it be possible? Does it mean that each side firstly uses the= share secret key and then uses signature method, namely doing authentica= tion twice to complete IKE_AUTH exchange? > Thanks for help. =20 > > =09 > > > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1DU Chun-yan > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1210313041@suda.edu.cn > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12006-02-28 > =20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 03 09:15:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFB43-0007Ya-9X; Fri, 03 Mar 2006 09:15:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFB42-0007UH-BU for ipsec@ietf.org; Fri, 03 Mar 2006 09:15:26 -0500 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFB40-0006jZ-Pt for ipsec@ietf.org; Fri, 03 Mar 2006 09:15:26 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k23EFGbW014096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Mar 2006 16:15:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id k23EF3Bu012032; Fri, 3 Mar 2006 16:15:03 +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: <17416.20327.286180.738855@fireball.kivinen.iki.fi> Date: Fri, 3 Mar 2006 16:15:03 +0200 From: Tero Kivinen To: Yoav Nir Subject: Re: [Ipsec] each side uses different authentication method? In-Reply-To: <4405521D.7080601@checkpoint.com> References: <20060301013239.88CC86CA09@proxy3.suda.edu.cn> <4405521D.7080601@checkpoint.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 11 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: =?GB2312?B?IrbFtLrR4ChEVSBDaHVuLXlhbiki?= <210313041@suda.edu.cn>, "ipsec@ietf.org" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Yoav Nir writes: > IMO it does not make sense at all. To get this done, you need to have > all of the following: > 1. B has no certificate, but trusts the CA. Like company installed laptop. > 2. There is a shared secret that is so good, that A trusts that anyone > who has it, must be B. Like group shared key...., note that A only trusts that B is part of group having that key. > If condition #2 holds, why do they need PKI? They can use the shared > secret. If it doesn't, how can A know that B is indeed B? Because everybody in the group B knows the shared key they can fake to be each other at will. If only shared key authentication would be used then anybody in the group B could also act as man in the middle between the another one in the group B and the real server A. If the members of group B uses certificates to authenticate the server A, this rules out the man in the middle attack, i.e. B can be sure that the communication is protected from the others in the group B too. The server A still cannot say who of the group B is really connecting, but in some environments that does not really matter, as long as the one connecting is part of group B. For example that kind of setup could be used to protect the connection between the laptop and the DHCP-server. By verifying the certificate of the DHCP-server the laptop really knows that the server is real DHCP server. By verifying the shared key of B the DHCP-server knows that this is approved machine, to whom he can give IP-address from the normal pool. This requires very little of enrollment as the laptops only needs to have the CA-certificate and the shared key, but they do not need to enroll their own private key and get certificate for it. This kind of asymmetric authentication isn't that much useful in the shared secret - certificates case, but it is needed in the EAP - certificates case. Also adding special case that would forbid using different authnetication methods in other cases would simply added more code, it was easier to simply allow it in all cases. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Mar 04 19:33:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFhBp-0005Jb-MQ; Sat, 04 Mar 2006 19:33:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFhBo-0005JW-Ta for ipsec@ietf.org; Sat, 04 Mar 2006 19:33:36 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFhBm-0003IQ-GS for ipsec@ietf.org; Sat, 04 Mar 2006 19:33:36 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k250XEEd014960 for ; Sat, 4 Mar 2006 17:33:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sat, 4 Mar 2006 16:33:08 -0800 To: IPsec WG From: Internet-Drafts@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [Ipsec] I-D ACTION:draft-hoffman-ikev2bis-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Key Exchange Protocol: IKEv2 Author(s) : P. Hoffman, et al. Filename : draft-hoffman-ikev2bis-00.txt Pages : 121 Date : 2006-3-3 This document describes version 2 of the Internet Key Exchange (IKE) protocol. It is a restatement of RFC 4306, and includes all of the clarifications from the "IKEv2 Clarifications" document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-ikev2bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hoffman-ikev2bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hoffman-ikev2bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Mar 05 18:29:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG2fB-0000yJ-RS; Sun, 05 Mar 2006 18:29:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG2fA-0000y8-FH for ipsec@ietf.org; Sun, 05 Mar 2006 18:29:20 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG2f8-0006B4-33 for ipsec@ietf.org; Sun, 05 Mar 2006 18:29:20 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k25NTG6W069238 for ; Sun, 5 Mar 2006 16:29:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sun, 5 Mar 2006 15:29:13 -0800 To: IPsec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ipsec] IKEv2bis, draft -00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Greetings again. A number of you objected to the idea of having an IKEv2.1 and felt that the clarifications to IKEv2 could be rolled into a document without having to change the version number. Based on that feedback, I created draft-hoffman-ikev2bis-00.txt with lots of help from Charlie and Pasi. See . (The IKEv2bis document completely replaces draft-hoffman-ikev2-1-00.txt, which is now dead, not to be revived.) Our intention is to create a new RFC that can replace RFC 4306. Because there is no version number change, an implementation of this new spec should interoperate with an implementation of RFC 4306 as well as (or better than!) two different implementations of RFC 4306 might have. We believe that implementations of this document will do that, although we are quite open to hearing where we might have gotten it wrong. We ask that all IKEv2 implementers read this draft and see if the changes from RFC 4306 are all correct. They should be the same as the changes made in the IKEv2 Clarifications document, but they are not word-for-word changes, so errors might have crept in. We are also interested in hearing suggestions for additional formatting changes for the document. For example, there have been requests to take informative material out of the Notify message tables and put it in the body of the document. We can do that in a future version of the draft, since it is just moving things around, not rewording. This is a big document, but we really hope to get sufficient input on it. The sooner we can close out this document, the sooner we have a stable, interoperable IKEv2. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Mar 20 17:18:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLShj-0005iH-Bv; Mon, 20 Mar 2006 17:18:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLShi-0005i9-GL for ipsec@ietf.org; Mon, 20 Mar 2006 17:18:22 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLShf-0006Xc-4H for ipsec@ietf.org; Mon, 20 Mar 2006 17:18:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k2KMIIQb024336 for ; Mon, 20 Mar 2006 23:18:18 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k2KMIG6C024332 for ; Mon, 20 Mar 2006 23:18:16 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k2KMIFtZ013195 for ; Mon, 20 Mar 2006 23:18:15 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200603202218.k2KMIFtZ013195@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@ietf.org Date: Mon, 20 Mar 2006 23:18:15 +0100 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ipsec] short question about KE format in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Quoting RFC 4306 section 3.4 page 56: The length of the Diffie-Hellman public value MUST be equal to the length of the prime modulus over which the exponentiation was performed, prepending zero bits to the value if necessary. Why such a MUST? Does it make sense for "groups" which are not MODP? Regards Francis.Dupont@point6.net _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Mar 20 19:28:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUjr-0006x2-QL; Mon, 20 Mar 2006 19:28:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUjq-0006wx-5c for ipsec@ietf.org; Mon, 20 Mar 2006 19:28:42 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLUjo-0004Em-Dg for ipsec@ietf.org; Mon, 20 Mar 2006 19:28:42 -0500 Received: from [130.129.134.198] (DHCP-Wireless-134-198.ietf65.org [130.129.134.198]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2L0ScZG037315 for ; Mon, 20 Mar 2006 17:28:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 20 Mar 2006 18:28:40 -0600 To: IPsec WG From: Internet-Drafts@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Ipsec] I-D ACTION:draft-manral-ipsec-rfc4305-errata-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH), Errata Author(s) : V. Manral Filename : draft-manral-ipsec-rfc4305-errata-00.txt Pages : 8 Date : 2006-3-20 Since the publication of the RFCs specifying the implementation requirements for ESP and AH, some errors have been noted. This informational document lists these errors and provides corrections for them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-manral-ipsec-rfc4305-errata-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-manral-ipsec-rfc4305-errata-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-manral-ipsec-rfc4305-errata-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 21 20:34:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLsEf-0006Wk-Dq; Tue, 21 Mar 2006 20:34:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLsEd-0006Wf-Vo for ipsec@ietf.org; Tue, 21 Mar 2006 20:34:03 -0500 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLsEc-0005mq-FK for ipsec@ietf.org; Tue, 21 Mar 2006 20:34:03 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k2M1Xdbc017335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Mar 2006 03:33:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k2M1XcSs014031; Wed, 22 Mar 2006 03:33:38 +0200 (EET) X-Authentication-Warning: fireball.acr.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: <17440.43378.383989.582000@fireball.acr.fi> Date: Wed, 22 Mar 2006 03:33:38 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Michele Bustos , Tim Van Herck , Merike Kaeo Subject: [Ipsec] IPsec performance drafts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Merike asked me to forward this email to ipsec-list: ---------------------------------------------------------------------- From: Merike Kaeo Subject: IPsec performance drafts Date: Tue, 21 Mar 2006 10:50:55 -0800 I've co-authored two documents relating to IPsec performance testing and as they're now fairly complete I'd like to solicit review and comments from the IPsec group. It would be great if people could send public comments to the bmwg wg (bmwg@ietf.org) but if people just want to send comments to the authors that's ok too [we'll summarize to bmwg]. Note that only IKEv1 is covered for now - the intent is to publish what's done and work on an IKEv2 doc in a separate document. The docs are: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ipsec-term-08.txt http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ipsec-meth-01.txt Thanks! - merike _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 22 10:24:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5C2-0005QT-S9; Wed, 22 Mar 2006 10:24:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5C1-0005O7-1d for ipsec@ietf.org; Wed, 22 Mar 2006 10:24:13 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM4J9-0001es-TH for ipsec@ietf.org; Wed, 22 Mar 2006 09:27:31 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FM4E4-0002uj-D3 for ipsec@ietf.org; Wed, 22 Mar 2006 09:22:19 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 22 Mar 2006 06:22:16 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,117,1141632000"; d="scan'208"; a="24184402:sNHT55362770" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2MEMAVY020208; Wed, 22 Mar 2006 09:22:15 -0500 (EST) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 09:22:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] IPsec performance drafts Date: Wed, 22 Mar 2006 09:22:10 -0500 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD60151DC19@xmb-rtp-208.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] IPsec performance drafts Thread-Index: AcZNUMOnQv3jTJCYQ8OzRn1+x0wULgAazFzQ From: "Stephane Beaulieu \(stephane\)" To: "Tero Kivinen" , X-OriginalArrivalTime: 22 Mar 2006 14:22:12.0097 (UTC) FILETIME=[02B0CF10:01C64DBC] X-Spam-Score: -2.0 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Michele Bustos , "Tim Van Herck \(herckt\)" , Merike Kaeo X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Is the goal of this draft to have an RFC that different vendors/testing firms can use to compare one product to another? Section 6.6.4 - Where's DH 5? Section 7.1 - If the goal is to measure 'sustained' sessions, why not send constant traffic through all established tunnels while initiating new tunnels, rather than just 50 packets. You should also specify the type and perhaps size of packets here also. You'd also need to specify psk vs. RSA, DH group, PFS, cipher algs, etc... Section 7.2 - How is 7.2 different than 7.1 test? Section 11.5 - P2 rekey frame loss? You aren't supposed to drop any packets during a P2 rekey, so why would you measure this? Section 13.1 - It looks like you're trying to serialize session establishment (i.e. wait until the first is complete before you start the 2nd one). This really isn't real world. If you want to set up 1 P1 with 100 P2's, you should be able to send 100 pkts as fast as you can and the DUT should then establish 100 P2's as fast as it can. Also, n should be the maximum number that the DUT supports. We've seen test results where the setup rate is x for the first 100 tunnels, but x/2 for the last 100 tunnels, when the tunnel counts get in the high 1000's. In our own internal testing, we don't even start counting the t.p.s. until we get to half of full capacity. This is more real-world. It's also unclear to me here if we're testing P1 or P2 or both. If we say n=3D100, does that mean a single P1 SA, and 100 P2 Sas? Or 100 P1's and 100 P2's? Also, do we need to test with or without PFS? Section 13.2 Again, this test serializes the session establishements which IMO is not a valid test. A better test is to send a single packet on each stream at an interval of x pps until you reach your max sessions. Where x is the t.p.s. that you're testing. If you reach max without any failures, then your tunnel setup rate is x. Try again with x+1. The highest x you achieve is your t.p.s. Again, remember that you must be able to maintain x t.p.s. even when the box is under heavy load, not just the first 100 tunnels. Section 13.3 - same comments as 13.1 Stephane.=20 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi]=20 > Sent: Tuesday, March 21, 2006 8:34 PM > To: ipsec@ietf.org > Cc: Michele Bustos; Tim Van Herck (herckt); Merike Kaeo > Subject: [Ipsec] IPsec performance drafts >=20 > Merike asked me to forward this email to ipsec-list: > ---------------------------------------------------------------------- > From: Merike Kaeo > Subject: IPsec performance drafts > Date: Tue, 21 Mar 2006 10:50:55 -0800 >=20 > I've co-authored two documents relating to IPsec performance=20 > testing and as they're now fairly complete I'd like to=20 > solicit review and comments from the IPsec group. It would=20 > be great if people could send public comments to the bmwg wg=20 > (bmwg@ietf.org) but if people just want to send comments to=20 > the authors that's ok too [we'll summarize to bmwg]. Note=20 > that only IKEv1 is covered for now - the intent is to publish=20 > what's done and work on an IKEv2 doc in a separate document. >=20 > The docs are: > http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ipsec-term-08.txt > http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ipsec-meth-01.txt >=20 > Thanks! >=20 > - merike >=20 >=20 >=20 >=20 > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 29 09:18:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FObUv-0004WQ-Ls; Wed, 29 Mar 2006 09:18:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FObUu-0004WB-CI for ipsec@ietf.org; Wed, 29 Mar 2006 09:18:08 -0500 Received: from smtp1.suda.edu.cn ([202.195.128.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FObUq-0006Tk-8U for ipsec@ietf.org; Wed, 29 Mar 2006 09:18:08 -0500 Received: from proxy3.suda.edu.cn ([202.195.128.8]) by smtp1.suda.edu.cn with InterScan Messaging Security Suite; Wed, 29 Mar 2006 22:33:41 +0800 Received: from dcy (unknown [192.168.150.110])by proxy3.suda.edu.cn (PMail) with ESMTP id 88CF26CA09for ; Wed, 29 Mar 2006 22:06:59 +0800 (CST) Date: Wed, 29 Mar 2006 22:19:42 +0800 From: "=?gb2312?B?ILbFtLrR4ChEVSBDaHVuLXlhbik=?=" <210313041@suda.edu.cn> To: "ipsec@ietf.org" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20060329140659.88CF26CA09@proxy3.suda.edu.cn> X-imss-version: 2.038 X-imss-result: Passed X-imss-scores: Clean:3.27613 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.8 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ipsec] question on draft "OCSP extension to IKEv2" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0608125249==" Errors-To: ipsec-bounces@ietf.org --===============0608125249== Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 SGksYWxsIQ0KDQoJQWNjb3JkaW5nIHRvIHNlY3Rpb24gMSBvZiBPQ1NQIEV4dGVuc2lvbnMgdG8g SUtFdjIoZHJhZnQtbXllcnMtaWtldjItb2NzcC0wMS50eHQpo7oNCiAgICChsENSTHMgY2FuIGhv d2V2ZXIgZ3JvdyB1bmJvdW5kZWQgaW4gc2l6ZS4gTWFueSByZWFsLXdvcmxkIGV4YW1wbGVzIGV4 aXN0IHRvIGRlbW9uc3RyYXRlIHRoZSBpbXByYWN0aWNhbGl0eSBvZiBpbmNsdWRpbmcgYSBtdWx0 aS1tZWdhYnl0ZSBmaWxlIGluIGFuIElLRSBleGNoYW5nZS4gVGhpcyBjb25zdHJhaW50IGlzIHBh cnRpY3VsYXJseSBhY3V0ZSBpbiBiYW5kd2lkdGggbGltaXRlZCBlbnZpcm9ubWVudHMgKGUuZy4g bW9iaWxlIGNvbW11bmljYXRpb25zKS4gVGhlIG5ldCBlZmZlY3QgaXMgZXhjbHVzaW9uIG9mIGlu LWJhbmQgQ1JMcyBpbiBmYXZvciBvZiBvdXQtb2YtYmFuZCAoT09CKSBhY3F1aXNpdGlvbiBvZiB0 aGVzZSBkYXRhLCBzaG91bGQgdGhleSBldmVuIGJlIHVzZWQgYXQgYWxsLg0KCVJlbGlhbmNlIG9u IE9PQiBtZXRob2RzIGNhbiBiZSBmdXJ0aGVyIGNvbXBsaWNhdGVkIGlmIGFjY2VzcyB0byByZXZv Y2F0aW9uIGRhdGEgcmVxdWlyZXMgdXNlIG9mIElQc2VjIChhbmQgdGhlcmVmb3JlIElLRSkgdG8g ZXN0YWJsaXNoIHNlY3VyZSBhbmQgYXV0aG9yaXplZCBhY2Nlc3MgdG8gdGhlIENSTHMgb2YgYW4g SUtFIHBhcnRpY2lwYW50LiBTdWNoIG5ldHdvcmsgYWNjZXNzIGRlYWRsb2NrIGZ1cnRoZXIgY29u dHJpYnV0ZXMgdG8gYSByZWR1Y2VkIHJlbGlhbmNlIG9uIGNlcnRpZmljYXRlIHJldm9jYXRpb24g c3RhdHVzIGluIGZhdm9yIG9mIGJsaW5kIHRydXN0LqGxDQoJDQoJVGhlbiBoZXJlIGlzIG15IHF1 ZXN0aW9uLA0KCSgxKXdoYXQgaXMgdGhlIG1lYW5pbmcgb2YgImluLWJhbmQiIGFuZCAib3V0LW9m LWJhbmQiIGluIElLRSBleGNoYW5nZT8gR2l2ZSBzb21lIGV4YW1wbGVzPyANCgkoMilEb2VzIE9P QiBuZWVkcyB0byB1c2UgSVBzZWMvSUtFIHRvIGFjY2VzcyB0byBDUkxzPyBUaGVuIGhvdyBkb2Vz IGl0IGNhdXNlIG5ldHdvcmsgYWNjZXNzIGRlYWRsb2NrPw0KDQpUaGFua3MgdmVyeSBtdWNoIGZv ciBhaGVhZCEgDQoJDQoNCgkJCQ0KUmVnYXJkLA0KCQkJCSANCqGhoaGhoaGhoaGhoaGhoaEgRFUg Q2h1bi15YW4NCqGhoaGhoaGhoaGhoaGhoaEyMTAzMTMwNDFAc3VkYS5lZHUuY24NCqGhoaGhoaGh oaGhoaGhoaGhoaGhMjAwNi0wMy0yOQ0KDQo= --===============0608125249== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0608125249==-- From ipsec-bounces@ietf.org Wed Mar 29 10:53:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOcxf-0007GA-Uv; Wed, 29 Mar 2006 10:51:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOcxf-0007Cy-1T for ipsec@ietf.org; Wed, 29 Mar 2006 10:51:55 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOcxZ-0002aJ-5V for ipsec@ietf.org; Wed, 29 Mar 2006 10:51:55 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k2TFpm8u003426 for ; Wed, 29 Mar 2006 08:51:48 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k2TFpmda014390 for ; Wed, 29 Mar 2006 08:51:48 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2TFplnO010013; Wed, 29 Mar 2006 09:51:47 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2TFplbo010012; Wed, 29 Mar 2006 09:51:47 -0600 (CST) Date: Wed, 29 Mar 2006 09:51:47 -0600 From: Nicolas Williams To: " ??????(DU Chun-yan)" <210313041@suda.edu.cn> Subject: Re: [Ipsec] question on draft "OCSP extension to IKEv2" Message-ID: <20060329155146.GK7525@binky.Central.Sun.COM> Mail-Followup-To: " ??????(DU Chun-yan)" <210313041@suda.edu.cn>, "ipsec@ietf.org" References: <20060329140659.88CF26CA09@proxy3.suda.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060329140659.88CF26CA09@proxy3.suda.edu.cn> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "ipsec@ietf.org" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org On Wed, Mar 29, 2006 at 10:19:42PM +0800, ??????(DU Chun-yan) wrote: > Hi,all! > > According to section 1 of OCSP Extensions to IKEv2(draft-myers-ikev2-ocsp-01.txt)?? > ??CRLs can however grow unbounded in size. Many real-world examples exist to demonstrate the impracticality of including a multi-megabyte file in an IKE exchange. This constraint is particularly acute in bandwidth limited environments (e.g. mobile communications). The net effect is exclusion of in-band CRLs in favor of out-of-band (OOB) acquisition of these data, should they even be used at all. > Reliance on OOB methods can be further complicated if access to revocation data requires use of IPsec (and therefore IKE) to establish secure and authorized access to the CRLs of an IKE participant. Such network access deadlock further contributes to a reduced reliance on certificate revocation status in favor of blind trust.?? > > Then here is my question, > (1)what is the meaning of "in-band" and "out-of-band" in IKE exchange? Give some examples? "in-band" -> sent on the wire in the same protocol's messages. "out-of-band" -> each peer gets the CRL for the other's cert via some means other than from the other peer in IKE messages, usually by talking HTTP to a CRL DP. > (2)Does OOB needs to use IPsec/IKE to access to CRLs? A host might have to use IPsec to talk to a CRL DP; I suspect this is not usually the case. > Then how > does it cause network access deadlock? I'm not sure that having to talk IPsec to a CRL DP causes deadlocks, but proxies and firewalls and what not might. Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 29 19:35:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOl8Y-00032S-2u; Wed, 29 Mar 2006 19:35:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOl8W-00032K-FT for ipsec@ietf.org; Wed, 29 Mar 2006 19:35:40 -0500 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOl8V-0002oQ-A9 for ipsec@ietf.org; Wed, 29 Mar 2006 19:35:40 -0500 Received: (qmail 2408 invoked by uid 0); 30 Mar 2006 00:35:30 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (71.246.201.221) by woodstock.binhost.com with SMTP; 30 Mar 2006 00:35:30 -0000 Message-Id: <7.0.0.16.2.20060329193457.02cd98e8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 29 Mar 2006 19:35:34 -0500 To: ipsec@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ipsec] IKEv1 Security Considerations X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org RFC 2409 says: Repeated re-keying using Quick Mode can consume the entropy of the Diffie-Hellman shared secret. Implementors should take note of this fact and set a limit on Quick Mode Exchanges between exponentiations. This memo does not prescribe such a limit. What limit do implementors impose? Russ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 30 05:33:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOuT8-0003hB-FS; Thu, 30 Mar 2006 05:33:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOuT6-0003h6-Lq for ipsec@ietf.org; Thu, 30 Mar 2006 05:33:32 -0500 Received: from smtp1.suda.edu.cn ([202.195.128.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOuT4-0004IG-Si for ipsec@ietf.org; Thu, 30 Mar 2006 05:33:32 -0500 Received: from proxy3.suda.edu.cn ([202.195.128.8]) by smtp1.suda.edu.cn with InterScan Messaging Security Suite; Thu, 30 Mar 2006 18:49:17 +0800 Received: from dcy (unknown [192.168.150.110])by proxy3.suda.edu.cn (PMail) with ESMTP id 6F22E6CA09for ; Thu, 30 Mar 2006 18:22:34 +0800 (CST) Date: Thu, 30 Mar 2006 18:35:16 +0800 From: "=?gb2312?B?ILbFtLrR4ChEVSBDaHVuLXlhbik=?=" <210313041@suda.edu.cn> To: "ipsec@ietf.org" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20060330102234.6F22E6CA09@proxy3.suda.edu.cn> X-imss-version: 2.038 X-imss-result: Passed X-imss-scores: Clean:50.37268 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.8 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Ipsec] Re: Ipsec Digest, Vol 23, Issue 7 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1225307237==" Errors-To: ipsec-bounces@ietf.org --===============1225307237== Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 DQo+PiAJVGhlbiBoZXJlIGlzIG15IHF1ZXN0aW9uLA0KPj4gCSgxKXdoYXQgaXMgdGhlIG1lYW5p bmcgb2YgImluLWJhbmQiIGFuZCAib3V0LW9mLWJhbmQiIGluIElLRSBleGNoYW5nZT8gR2l2ZSBz b21lIGV4YW1wbGVzPyANCj4NCj4iaW4tYmFuZCIgLT4gc2VudCBvbiB0aGUgd2lyZSBpbiB0aGUg c2FtZSBwcm90b2NvbCdzIG1lc3NhZ2VzLg0KPg0KPiJvdXQtb2YtYmFuZCIgLT4gZWFjaCBwZWVy IGdldHMgdGhlIENSTCBmb3IgdGhlIG90aGVyJ3MgY2VydCB2aWEgc29tZQ0KPiAgICAgICAgICAg ICAgICAgbWVhbnMgb3RoZXIgdGhhbiBmcm9tIHRoZSBvdGhlciBwZWVyIGluIElLRSBtZXNzYWdl cywNCj4JCSB1c3VhbGx5IGJ5IHRhbGtpbmcgSFRUUCB0byBhIENSTCBEUC4NCj4NCj4+IAkoMilE b2VzIE9PQiBuZWVkcyB0byB1c2UgSVBzZWMvSUtFIHRvIGFjY2VzcyB0byBDUkxzPw0KPg0KPkEg aG9zdCBtaWdodCBoYXZlIHRvIHVzZSBJUHNlYyB0byB0YWxrIHRvIGEgQ1JMIERQOyBJIHN1c3Bl Y3QgdGhpcyBpcw0KPm5vdCB1c3VhbGx5IHRoZSBjYXNlLg0KPg0KPj4gCSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoZW4gaG93DQo+PiAJZG9l cyBpdCBjYXVzZSBuZXR3b3JrIGFjY2VzcyBkZWFkbG9jaz8NCj4NCj5JJ20gbm90IHN1cmUgdGhh dCBoYXZpbmcgdG8gdGFsayBJUHNlYyB0byBhIENSTCBEUCBjYXVzZXMgZGVhZGxvY2tzLCBidXQN Cj5wcm94aWVzIGFuZCBmaXJld2FsbHMgYW5kIHdoYXQgbm90IG1pZ2h0Lg0KPg0KPk5pY28NCj4t LSANCj4NCglUaGFuayB5b3UgZm9yIHJlcGx5ISBBcmUgdGhlcmUgYW55IG1vcmUgdmlld3M/IA0K CQ0KCVF1ZXN0aW9uIDM6IFdoYXQgZG8gT0NTUCBSZXNwb25kZXIgSGFzaCBhbmQgT0NTUCBSZXNw b25zZSBvbiBlYXJ0aCBwcmVzZW50IGZvcj8gDQoJSSB0aGluayBPQ1NQIFJlc3BvbmRlciBIYXNo IGlzIHVzZWQgZm9yIHRoZSBzZW5kZXIgdG8gbm90aWZ5IHRoZSByZWNlaXZlciB3aGljaCBPQ1NQ IFJlc3BvbmRlciBpdCB0cnVzdHMsIGp1c3QgbGlrZSB0aGUgZnVuY3Rpb24gb2YgQ2VydGlmaWNh dGUgQXV0aG9yaXR5IGluIENFUlRSRVEgcGF5bG9hZC4gSXQgaXMgdGhlIHJlY2VpdmVyJ3MgZHV0 eSB0byBmb3JtIGFuIE9DU1AgcmVxdWVzdCB0byB0aGUgT0NTUCBSZXNwb25kZXIuIEFmdGVyIGdl dHRpbmcgdGhlIE9DU1AgcmVzcG9uc2UsIHRoZSByZWNlaXZlciBoYXMgdG8gZm9ybSBhbmQgdHJh bnNtaXQgT0NTUCBSZXNwb25zZSBDRVJUIHBheWxvYWQuIEFjY29yZGluZyB0byB0aGUgT0NTUCBS ZXNwb25zZSBDRVJULCB0aGUgb3RoZXIgcGVlciBtYXkgYWJvcnQgdGhlIElLRXYyIGV4Y2hhbmdl IGlmIGl0IGluZGljYXRlcyB0aGUgY2VydGlmaWNhdGUgaXMgcmV2b2tlZCBvciBPQ1NQIGVycm9y LiBJcyBpdCB0cnVlPw0KCUlmIHRoaXMgaXMgdGhlIGNhc2UsIHRoZW4gSSBjb25mdXNlZCB0aGF0 IHdoeSB0aGUgcmVjZWl2ZXIgc3RpbGwgc2VuZHMgdGhlIGNlcnRpZmljYXRlIGluIENFUlQgYW5k IE9DU1AgUmVzcG9uZGVyIENFUlQgbm93IHRoYXQgdGhlIE9DU1AgcmVzcG9uc2UgQ0VSVCBpbmRp Y2F0ZXMgdGhhdCBjZXJ0aWZpY2F0ZSBpcyByZXZva2VkIG9yIE9DU1AgZXJyb3IsIHNob3VsZCBp dCBhYm9ydCB0aGUgZXhjaGFuZ2UgdGhlbj8gTW9yZW92ZXIsIGhvdyB0byBkZWFsIHdpdGggdGhl ICJ0cnkgbGF0ZXIiIE9DU1AgcmVzcG9uc2U/ICAgICANCg0KICAgIFRoYW5rcyBmb3IgaGVscCEN CgkNClJlZ2FyZHMsCQkJIA0KoaGhoaGhoaGhoaGhoaEgICAgRFUgQ2h1bi15YW4NCqGhoaGhoaGh oaGhoaGhoaEyMTAzMTMwNDFAc3VkYS5lZHUuY24NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNi0w My0zMA0KDQo= --===============1225307237== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1225307237==-- From ipsec-bounces@ietf.org Thu Mar 30 20:57:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP8sY-0005C4-OS; Thu, 30 Mar 2006 20:56:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP8sX-0005Bw-Mh for ipsec@ietf.org; Thu, 30 Mar 2006 20:56:45 -0500 Received: from smtp1.suda.edu.cn ([202.195.128.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP8sT-0004ib-E9 for ipsec@ietf.org; Thu, 30 Mar 2006 20:56:45 -0500 Received: from proxy3.suda.edu.cn ([202.195.128.8]) by smtp1.suda.edu.cn with InterScan Messaging Security Suite; Fri, 31 Mar 2006 10:12:42 +0800 Received: from dcy (unknown [192.168.150.110])by proxy3.suda.edu.cn (PMail) with ESMTP id 868846CA09for ; Fri, 31 Mar 2006 09:45:58 +0800 (CST) Date: Fri, 31 Mar 2006 09:58:40 +0800 From: "=?gb2312?B?ILbFtLrR4ChEVSBDaHVuLXlhbik=?=" <210313041@suda.edu.cn> To: "ipsec@ietf.org" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20060331014558.868846CA09@proxy3.suda.edu.cn> X-imss-version: 2.038 X-imss-result: Passed X-imss-scores: Clean:12.72851 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.8 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Ipsec] questions about OCSP in IKEv2(2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1307003982==" Errors-To: ipsec-bounces@ietf.org --===============1307003982== Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 SGVsbG8sYWxsIQ0KICAgICAgQWNjb3JkaW5nIHRvIHNlY3Rpb24gMSBvZiBPQ1NQIEV4dGVuc2lv bnMgdG8gSUtFdjIoZHJhZnQtbXllcnMtaWtldjItb2NzcC0wMS50eHQpo7oNCiAgICChsENSTHMg Y2FuIGhvd2V2ZXIgZ3JvdyB1bmJvdW5kZWQgaW4gc2l6ZS4gTWFueSByZWFsLXdvcmxkIGV4YW1w bGVzIGV4aXN0IHRvIGRlbW9uc3RyYXRlIHRoZSBpbXByYWN0aWNhbGl0eSBvZiBpbmNsdWRpbmcg YSBtdWx0aS1tZWdhYnl0ZSBmaWxlIGluIGFuIElLRSBleGNoYW5nZS4gVGhpcyBjb25zdHJhaW50 IGlzIHBhcnRpY3VsYXJseSBhY3V0ZSBpbiBiYW5kd2lkdGggbGltaXRlZCBlbnZpcm9ubWVudHMg KGUuZy4gbW9iaWxlIGNvbW11bmljYXRpb25zKS4gVGhlIG5ldCBlZmZlY3QgaXMgZXhjbHVzaW9u IG9mIGluLWJhbmQgQ1JMcyBpbiBmYXZvciBvZiBvdXQtb2YtYmFuZCAoT09CKSBhY3F1aXNpdGlv biBvZiB0aGVzZSBkYXRhLCBzaG91bGQgdGhleSBldmVuIGJlIHVzZWQgYXQgYWxsLg0KIFJlbGlh bmNlIG9uIE9PQiBtZXRob2RzIGNhbiBiZSBmdXJ0aGVyIGNvbXBsaWNhdGVkIGlmIGFjY2VzcyB0 byByZXZvY2F0aW9uIGRhdGEgcmVxdWlyZXMgdXNlIG9mIElQc2VjIChhbmQgdGhlcmVmb3JlIElL RSkgdG8gZXN0YWJsaXNoIHNlY3VyZSBhbmQgYXV0aG9yaXplZCBhY2Nlc3MgdG8gdGhlIENSTHMg b2YgYW4gSUtFIHBhcnRpY2lwYW50LiBTdWNoIG5ldHdvcmsgYWNjZXNzIGRlYWRsb2NrIGZ1cnRo ZXIgY29udHJpYnV0ZXMgdG8gYSByZWR1Y2VkIHJlbGlhbmNlIG9uIGNlcnRpZmljYXRlIHJldm9j YXRpb24gc3RhdHVzIGluIGZhdm9yIG9mIGJsaW5kIHRydXN0LqGxDQogDQogVGhlbiBoZXJlIGlz IG15IHF1ZXN0aW9uLA0KICgxKXdoYXQgaXMgdGhlIG1lYW5pbmcgb2YgImluLWJhbmQiIGFuZCAi b3V0LW9mLWJhbmQiIGluIElLRSBleGNoYW5nZT8gR2l2ZSBzb21lIGV4YW1wbGVzPyANCiAoMilE b2VzIE9PQiBuZWVkcyB0byB1c2UgSVBzZWMvSUtFIHRvIGFjY2VzcyB0byBDUkxzPyBUaGVuIGhv dyBkb2VzIGl0IGNhdXNlIG5ldHdvcmsgYWNjZXNzIGRlYWRsb2NrPw0KICgzKVdoYXQgZG8gT0NT UCBSZXNwb25kZXIgSGFzaCBhbmQgT0NTUCBSZXNwb25zZSBvbiBlYXJ0aCBwcmVzZW50IGZvcj8g DQogIEkgdGhpbmsgT0NTUCBSZXNwb25kZXIgSGFzaCBpcyB1c2VkIGZvciB0aGUgc2VuZGVyIHRv IG5vdGlmeSB0aGUgcmVjZWl2ZXIgd2hpY2ggT0NTUCBSZXNwb25kZXIgaXQgdHJ1c3RzLCBqdXN0 IGxpa2UgdGhlIGZ1bmN0aW9uIG9mIENlcnRpZmljYXRlIEF1dGhvcml0eSBpbiBDRVJUUkVRIHBh eWxvYWQuIEl0IGlzIHRoZSByZWNlaXZlcidzIGR1dHkgdG8gZm9ybSBhbiBPQ1NQIHJlcXVlc3Qg dG8gdGhlIE9DU1AgUmVzcG9uZGVyLiBBZnRlciBnZXR0aW5nIHRoZSBPQ1NQIHJlc3BvbnNlLCB0 aGUgcmVjZWl2ZXIgaGFzIHRvIGZvcm0gYW5kIHRyYW5zbWl0IE9DU1AgUmVzcG9uc2UgQ0VSVCBw YXlsb2FkLiBBY2NvcmRpbmcgdG8gdGhlIE9DU1AgUmVzcG9uc2UgQ0VSVCwgdGhlIG90aGVyIHBl ZXIgbWF5IGFib3J0IHRoZSBJS0V2MiBleGNoYW5nZSBpZiBpdCBpbmRpY2F0ZXMgdGhlIGNlcnRp ZmljYXRlIGlzIHJldm9rZWQgb3IgT0NTUCBlcnJvci4gSXMgaXQgdHJ1ZT8NCiAgSWYgdGhpcyBp cyB0aGUgY2FzZSwgdGhlbiBJIGNvbmZ1c2VkIHRoYXQgd2h5IHRoZSByZWNlaXZlciBzdGlsbCBz ZW5kcyB0aGUgY2VydGlmaWNhdGUgaW4gQ0VSVCBhbmQgT0NTUCBSZXNwb25kZXIgQ0VSVCBub3cg dGhhdCB0aGUgT0NTUCByZXNwb25zZSBDRVJUIGluZGljYXRlcyB0aGF0IGNlcnRpZmljYXRlIGlz IHJldm9rZWQgb3IgT0NTUCBlcnJvciwgc2hvdWxkIGl0IGFib3J0IHRoZSBleGNoYW5nZSBhdCBv bmNlPyBNb3Jlb3ZlcixzaG91bGQgaXQgYmUgYmV0dGVyIGZvciB0aGUgc2VuZGVyIG9mIE9DU1Ag UmVzcG9uZGVyIEhhc2ggY2hlY2tzIGZvciB0aGUgY2VydGlmaWNhdGUgc3RhdHVzPw0KDQogIFRo YW5rIHlvdSBmb3IgYWhlYWQhDQoNCgkNClJlZ2FyZHMsDQoJCQkgDQqhoaGhoaGhoaGhoaGhoaGh IERVIENodW4teWFuDQqhoaGhoaGhoaGhoaGhoaGhMjEwMzEzMDQxQHN1ZGEuZWR1LmNuDQqhoaGh oaGhoaGhoaGhoaGhoaGhoTIwMDYtMDMtMzENCg0K --===============1307003982== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1307003982==-- From ipsec-bounces@ietf.org Fri Mar 31 01:57:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPDZ8-0000Vw-4f; Fri, 31 Mar 2006 01:57:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPDZ6-0000Vg-QQ for ipsec@ietf.org; Fri, 31 Mar 2006 01:57:00 -0500 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPDZ3-0008Ii-BJ for ipsec@ietf.org; Fri, 31 Mar 2006 01:57:00 -0500 Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 22:56:57 -0800 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.69.171) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.516.4; Thu, 30 Mar 2006 22:56:56 -0800 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 22:56:56 -0800 From: Charlie Kaufman To: "=?utf-8?Q?_=E6=9D=9C=E6=98=A5=E7=87=95(DU_Chun-yan)?=" <210313041@suda.edu.cn>, "ipsec@ietf.org" Date: Thu, 30 Mar 2006 22:56:54 -0800 Subject: RE: [Ipsec] questions about OCSP in IKEv2(2) Thread-Topic: [Ipsec] questions about OCSP in IKEv2(2) Thread-Index: AcZUZoGV+wDDHx33RH+nuDyvErwvDQAJz6Ag Message-ID: In-Reply-To: <20060331014558.868846CA09@proxy3.suda.edu.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-RulesExecuted: True X-OriginalArrivalTime: 31 Mar 2006 06:56:56.0028 (UTC) FILETIME=[4C63F1C0:01C65490] x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1423600393==" Errors-To: ipsec-bounces@ietf.org --===============1423600393== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PlRoZW4gaGVyZSBpcyBteSBxdWVzdGlvbiwNCj4gKDEpd2hhdCBpcyB0aGUgbWVhbmluZyBvZiAi aW4tYmFuZCIgYW5kICJvdXQtb2YtYmFuZCIgaW4gSUtFIGV4Y2hhbmdlPyA+R2l2ZSBzb21lIGV4 YW1wbGVzPw0KDQpJS0V2MiBhbGxvd3Mgc29tZSBwb3RlbnRpYWxseSBsYXJnZSBkYXRhIGl0ZW1z IChsaWtlIGNlcnRpZmljYXRlcyBhbmQgQ1JMcykgdG8gYmUgc2VudCAib3V0IG9mIGJhbmQiLiBU aGlzIG1lYW5zIHRoYXQgaW4gdGhlIElLRXYyIGV4Y2hhbmdlLCBpbnN0ZWFkIG9mIGluY2x1ZGlu ZyB0aGUgbGFyZ2UgZGF0YSBpdGVtcyB0aGUgSUtFdjIgbWVzc2FnZSBjYXJyaWVzIGEgY3J5cHRv Z3JhcGhpYyBoYXNoIG9mIHRoZSBkYXRhIGFuZCBhIFVSTCBmcm9tIHdoaWNoIHRoZSBkYXRhIGNh biBiZSBmZXRjaGVkLiBSZXRyaWV2aW5nIHRoZXNlIFVSTHMgY2FuIHJ1biBvdmVyIGEgZGlmZmVy ZW50IHByb3RvY29sICh1c3VhbGx5IGh0dHApIHRoYXQgcnVucyBvdmVyIFRDUCBhbmQgY2FuIHRo ZXJlZm9yZSBiZXR0ZXIgY29wZSB3aXRoIGxhcmdlIGRhdGEgaXRlbXMuDQoNCg0KPiAoMilEb2Vz IE9PQiBuZWVkcyB0byB1c2UgSVBzZWMvSUtFIHRvIGFjY2VzcyB0byBDUkxzPyBUaGVuIGhvdyBk b2VzIGl0ID5jYXVzZSBuZXR3b3JrIGFjY2VzcyBkZWFkbG9jaz8NCg0KSW4gc29tZSBjb25maWd1 cmF0aW9ucywgdGhlIG9ubHkgd2F5IGFuIGVuZHBvaW50IGNhbiByZXRyaWV2ZSB0aGUgVVJMIG5h bWVkIGluIHRoZSBJS0V2MiBleGNoYW5nZSBpcyBieSB0dW5uZWxpbmcgdGhlIHJlcXVlc3Qgb3Zl ciB0aGUgSVBzZWMgY29ubmVjdGlvbiBiZWluZyBlc3RhYmxpc2hlZC4gRm9yIGV4YW1wbGUsIGlm IG15IGxhcHRvcCBpcyBjcmVhdGluZyBhbiBJUHNlYyB0dW5uZWwgdG8gbXkgY29ycG9yYXRlIGlu dHJhbmV0IGFuZCB0aGUgQ1JMIGlzIG9ubHkgYXZhaWxhYmxlIG9uIHRoZSBjb3Jwb3JhdGUgaW50 cmFuZXQsIHRoZW4gSSBjYW5ub3QgcmV0cmlldmUgdGhlIENSTCB1bnRpbCBJIGhhdmUgY29tcGxl dGVkIHRoZSBJS0V2MiBleGNoYW5nZS4gSWYgSSByZWZ1c2VkIHRvIGNvbXBsZXRlIHRoZSBjcmVh dGlvbiBvZiB0aGUgSVBzZWMgdHVubmVsIHVudGlsIEkgaGFkIHZlcmlmaWVkIHRoZSBDUkwsIHRo aXMgd291bGQgY3JlYXRlIGEgZGVhZGxvY2suDQoNClRoaXMgY2FuIGluIHByYWN0aWNlIGJlIGF2 b2lkZWQgYnkgc29mdHdhcmUgdGhhdCBjb25kaXRpb25hbGx5IG9wZW5zIHRoZSBJUHNlYyB0dW5u ZWwgYmVmb3JlIHZlcmlmeWluZyB0aGUgQ1JMLiBJdCBjYW4gdGhlbiByZXRyaWV2ZSB0aGUgQ1JM IG92ZXIgdGhlIElQc2VjIHR1bm5lbCwgdmVyaWZ5IGl0LCBhbmQgdGhlbiBvcGVuIHRoZSBJUHNl YyB0dW5uZWwgZm9yIG90aGVyIHVzZXMuDQoNClVuZm9ydHVuYXRlbHksIHdoaWxlIHNpbXBsZSB0 byBkZXNjcmliZSBpdCBjYW4gYmUgZGlmZmljdWx0IHRvIGltcGxlbWVudCBkZXBlbmRpbmcgb24g aG93IHRoZSBzb2Z0d2FyZSBvbiB0aGUgZW5kcG9pbnQgaXMgc3RydWN0dXJlZC4NCg0KPiAoMylX aGF0IGRvIE9DU1AgUmVzcG9uZGVyIEhhc2ggYW5kIE9DU1AgUmVzcG9uc2Ugb24gZWFydGggcHJl c2VudCBmb3I/DQoNCkkgZG9uJ3Qga25vdy4gUGVyaGFwcyBzb21lb25lIGVsc2Ugb24gdGhpcyBs aXN0IGNhbiBoZWxwIHdpdGggdGhpcyBvbmUuDQoNCiAgICAgICAgLS1DaGFybGllIEthdWZtYW4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IOadnOaYpeeHlShEVSBDaHVuLXlh bikgW21haWx0bzoyMTAzMTMwNDFAc3VkYS5lZHUuY25dDQpTZW50OiBUaHVyc2RheSwgTWFyY2gg MzAsIDIwMDYgNTo1OSBQTQ0KVG86IGlwc2VjQGlldGYub3JnDQpTdWJqZWN0OiBbSXBzZWNdIHF1 ZXN0aW9ucyBhYm91dCBPQ1NQIGluIElLRXYyKDIpDQoNCkhlbGxvLGFsbCENCiAgICAgIEFjY29y ZGluZyB0byBzZWN0aW9uIDEgb2YgT0NTUCBFeHRlbnNpb25zIHRvIElLRXYyKGRyYWZ0LW15ZXJz LWlrZXYyLW9jc3AtMDEudHh0Ke+8mg0KICAgIOKAnENSTHMgY2FuIGhvd2V2ZXIgZ3JvdyB1bmJv dW5kZWQgaW4gc2l6ZS4gTWFueSByZWFsLXdvcmxkIGV4YW1wbGVzIGV4aXN0IHRvIGRlbW9uc3Ry YXRlIHRoZSBpbXByYWN0aWNhbGl0eSBvZiBpbmNsdWRpbmcgYSBtdWx0aS1tZWdhYnl0ZSBmaWxl IGluIGFuIElLRSBleGNoYW5nZS4gVGhpcyBjb25zdHJhaW50IGlzIHBhcnRpY3VsYXJseSBhY3V0 ZSBpbiBiYW5kd2lkdGggbGltaXRlZCBlbnZpcm9ubWVudHMgKGUuZy4gbW9iaWxlIGNvbW11bmlj YXRpb25zKS4gVGhlIG5ldCBlZmZlY3QgaXMgZXhjbHVzaW9uIG9mIGluLWJhbmQgQ1JMcyBpbiBm YXZvciBvZiBvdXQtb2YtYmFuZCAoT09CKSBhY3F1aXNpdGlvbiBvZiB0aGVzZSBkYXRhLCBzaG91 bGQgdGhleSBldmVuIGJlIHVzZWQgYXQgYWxsLg0KIFJlbGlhbmNlIG9uIE9PQiBtZXRob2RzIGNh biBiZSBmdXJ0aGVyIGNvbXBsaWNhdGVkIGlmIGFjY2VzcyB0byByZXZvY2F0aW9uIGRhdGEgcmVx dWlyZXMgdXNlIG9mIElQc2VjIChhbmQgdGhlcmVmb3JlIElLRSkgdG8gZXN0YWJsaXNoIHNlY3Vy ZSBhbmQgYXV0aG9yaXplZCBhY2Nlc3MgdG8gdGhlIENSTHMgb2YgYW4gSUtFIHBhcnRpY2lwYW50 LiBTdWNoIG5ldHdvcmsgYWNjZXNzIGRlYWRsb2NrIGZ1cnRoZXIgY29udHJpYnV0ZXMgdG8gYSBy ZWR1Y2VkIHJlbGlhbmNlIG9uIGNlcnRpZmljYXRlIHJldm9jYXRpb24gc3RhdHVzIGluIGZhdm9y IG9mIGJsaW5kIHRydXN0LuKAnQ0KDQogVGhlbiBoZXJlIGlzIG15IHF1ZXN0aW9uLA0KICgxKXdo YXQgaXMgdGhlIG1lYW5pbmcgb2YgImluLWJhbmQiIGFuZCAib3V0LW9mLWJhbmQiIGluIElLRSBl eGNoYW5nZT8gR2l2ZSBzb21lIGV4YW1wbGVzPw0KICgyKURvZXMgT09CIG5lZWRzIHRvIHVzZSBJ UHNlYy9JS0UgdG8gYWNjZXNzIHRvIENSTHM/IFRoZW4gaG93IGRvZXMgaXQgY2F1c2UgbmV0d29y ayBhY2Nlc3MgZGVhZGxvY2s/DQogKDMpV2hhdCBkbyBPQ1NQIFJlc3BvbmRlciBIYXNoIGFuZCBP Q1NQIFJlc3BvbnNlIG9uIGVhcnRoIHByZXNlbnQgZm9yPw0KICBJIHRoaW5rIE9DU1AgUmVzcG9u ZGVyIEhhc2ggaXMgdXNlZCBmb3IgdGhlIHNlbmRlciB0byBub3RpZnkgdGhlIHJlY2VpdmVyIHdo aWNoIE9DU1AgUmVzcG9uZGVyIGl0IHRydXN0cywganVzdCBsaWtlIHRoZSBmdW5jdGlvbiBvZiBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkgaW4gQ0VSVFJFUSBwYXlsb2FkLiBJdCBpcyB0aGUgcmVjZWl2 ZXIncyBkdXR5IHRvIGZvcm0gYW4gT0NTUCByZXF1ZXN0IHRvIHRoZSBPQ1NQIFJlc3BvbmRlci4g QWZ0ZXIgZ2V0dGluZyB0aGUgT0NTUCByZXNwb25zZSwgdGhlIHJlY2VpdmVyIGhhcyB0byBmb3Jt IGFuZCB0cmFuc21pdCBPQ1NQIFJlc3BvbnNlIENFUlQgcGF5bG9hZC4gQWNjb3JkaW5nIHRvIHRo ZSBPQ1NQIFJlc3BvbnNlIENFUlQsIHRoZSBvdGhlciBwZWVyIG1heSBhYm9ydCB0aGUgSUtFdjIg ZXhjaGFuZ2UgaWYgaXQgaW5kaWNhdGVzIHRoZSBjZXJ0aWZpY2F0ZSBpcyByZXZva2VkIG9yIE9D U1AgZXJyb3IuIElzIGl0IHRydWU/DQogIElmIHRoaXMgaXMgdGhlIGNhc2UsIHRoZW4gSSBjb25m dXNlZCB0aGF0IHdoeSB0aGUgcmVjZWl2ZXIgc3RpbGwgc2VuZHMgdGhlIGNlcnRpZmljYXRlIGlu IENFUlQgYW5kIE9DU1AgUmVzcG9uZGVyIENFUlQgbm93IHRoYXQgdGhlIE9DU1AgcmVzcG9uc2Ug Q0VSVCBpbmRpY2F0ZXMgdGhhdCBjZXJ0aWZpY2F0ZSBpcyByZXZva2VkIG9yIE9DU1AgZXJyb3Is IHNob3VsZCBpdCBhYm9ydCB0aGUgZXhjaGFuZ2UgYXQgb25jZT8gTW9yZW92ZXIsc2hvdWxkIGl0 IGJlIGJldHRlciBmb3IgdGhlIHNlbmRlciBvZiBPQ1NQIFJlc3BvbmRlciBIYXNoIGNoZWNrcyBm b3IgdGhlIGNlcnRpZmljYXRlIHN0YXR1cz8NCg0KICBUaGFuayB5b3UgZm9yIGFoZWFkIQ0KDQoN ClJlZ2FyZHMsDQoNCuOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgCBEVSBDaHVuLXlhbg0K44CA44CA 44CA44CA44CA44CA44CA44CAMjEwMzEzMDQxQHN1ZGEuZWR1LmNuDQrjgIDjgIDjgIDjgIDjgIDj gIDjgIDjgIDjgIDjgIAyMDA2LTAzLTMxDQoNCg== --===============1423600393== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1423600393==-- From ipsec-bounces@ietf.org Fri Mar 31 02:34:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPE7Y-0006Ss-Tx; Fri, 31 Mar 2006 02:32:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPE7W-0006S3-NM for ipsec@ietf.org; Fri, 31 Mar 2006 02:32:34 -0500 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPE7R-0001jN-7z for ipsec@ietf.org; Fri, 31 Mar 2006 02:32:33 -0500 Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 23:32:29 -0800 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.69.171) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.516.4; Thu, 30 Mar 2006 23:32:19 -0800 Received: from df-bhd-01.exchange.corp.microsoft.com ([157.54.54.216]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Mar 2006 23:32:19 -0800 From: Charlie Kaufman To: Francis Dupont , "ipsec@ietf.org" Date: Thu, 30 Mar 2006 23:32:18 -0800 Subject: RE: [Ipsec] short question about KE format in IKEv2 Thread-Topic: [Ipsec] short question about KE format in IKEv2 Thread-Index: AcZMbFUUj94f5K8dT76jnNif+79zBwIJzk/A Message-ID: In-Reply-To: <200603202218.k2KMIFtZ013195@givry.rennes.enst-bretagne.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RulesExecuted: True X-OriginalArrivalTime: 31 Mar 2006 07:32:19.0314 (UTC) FILETIME=[3DF7AD20:01C65495] x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org The text may have to be clarified for groups that are not MODP. The reason for the MUST is to save implementers some work. When a Diffie-Hellman private/public pair is chosen at random, there is a 1= /256 chance that the high order 8 bits of the public pair will all be zeros= (actually slightly more than that because the prime modulus is less than 2= ^n) and a 1/(2^16) chance the high order 18 bits will all be zeros. In some implementations (depending on the interface to the crypto library),= it would be more natural to trim off the high order zero bytes and send a = shorter KE value in that case. For others, it would be more natural to send= a fixed size buffer even if the high order bits are all zero. If the specification did not say whether to trim off the high order zero by= tes or not, then all implementations would have to be prepared to receive e= ither full size or truncated KE values and pad them out. By saying that the= padded value MUST be sent, we make it simpler for recipients at the expens= e of making it a little harder for some senders. There is probably an equivalent problem with ECC Diffie-Hellman - if the EC= C public number is thought of as an integer, some crypto libraries might tr= uncate it. Mathematically, I believe the ECC public number is a bit string = rather than an integer, so it might be "obvious" that an implementation MUS= T always send a KE value whose length is the largest size possible given th= e negotiated ECC group. --Charlie -----Original Message----- From: Francis Dupont [mailto:Francis.Dupont@point6.net] Sent: Monday, March 20, 2006 2:18 PM To: ipsec@ietf.org Subject: [Ipsec] short question about KE format in IKEv2 Quoting RFC 4306 section 3.4 page 56: The length of the Diffie-Hellman public value MUST be equal to the length of the prime modulus over which the exponentiation was performed, prepending zero bits to the value if necessary. Why such a MUST? Does it make sense for "groups" which are not MODP? Regards Francis.Dupont@point6.net _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 31 06:29:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPHoU-0000iu-VC; Fri, 31 Mar 2006 06:29:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPHoU-0000ip-7q for ipsec@ietf.org; Fri, 31 Mar 2006 06:29:10 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPHoT-0004i6-Pn for ipsec@ietf.org; Fri, 31 Mar 2006 06:29:10 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2VBRkTM031279 for ; Fri, 31 Mar 2006 14:27:47 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Mar 2006 14:29:07 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Mar 2006 14:29:07 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] short question about KE format in IKEv2 Date: Fri, 31 Mar 2006 14:29:10 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] short question about KE format in IKEv2 Thread-Index: AcZMbFUUj94f5K8dT76jnNif+79zBwIJzk/AAAhpxpA= From: To: X-OriginalArrivalTime: 31 Mar 2006 11:29:07.0215 (UTC) FILETIME=[528951F0:01C654B6] X-Spam-Score: 0.2 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org At least the "Field Element to Octet String" conversion function in X9.62-2005 Section A.5.4 always produces an output of the same length (padding the octet string with zeroes if necessary). Thus, it seems the requirement does make sense for ECC as well. Best regards, Pasi > -----Original Message----- > From: ext Charlie Kaufman [mailto:charliek@exchange.microsoft.com]=20 > Sent: 31 March, 2006 10:32 > To: Francis Dupont; ipsec@ietf.org > Subject: RE: [Ipsec] short question about KE format in IKEv2 >=20 > The text may have to be clarified for groups that are not MODP. >=20 > The reason for the MUST is to save implementers some work. >=20 > When a Diffie-Hellman private/public pair is chosen at=20 > random, there is a 1/256 chance that the high order 8 bits of=20 > the public pair will all be zeros (actually slightly more=20 > than that because the prime modulus is less than 2^n) and a=20 > 1/(2^16) chance the high order 18 bits will all be zeros. >=20 > In some implementations (depending on the interface to the=20 > crypto library), it would be more natural to trim off the=20 > high order zero bytes and send a shorter KE value in that=20 > case. For others, it would be more natural to send a fixed=20 > size buffer even if the high order bits are all zero. >=20 > If the specification did not say whether to trim off the high=20 > order zero bytes or not, then all implementations would have=20 > to be prepared to receive either full size or truncated KE=20 > values and pad them out. By saying that the padded value MUST=20 > be sent, we make it simpler for recipients at the expense of=20 > making it a little harder for some senders. >=20 > There is probably an equivalent problem with ECC=20 > Diffie-Hellman - if the ECC public number is thought of as an=20 > integer, some crypto libraries might truncate it.=20 > Mathematically, I believe the ECC public number is a bit=20 > string rather than an integer, so it might be "obvious" that=20 > an implementation MUST always send a KE value whose length is=20 > the largest size possible given the negotiated ECC group. >=20 > --Charlie >=20 > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@point6.net] > Sent: Monday, March 20, 2006 2:18 PM > To: ipsec@ietf.org > Subject: [Ipsec] short question about KE format in IKEv2 >=20 > Quoting RFC 4306 section 3.4 page 56: >=20 > The length of the Diffie-Hellman public value MUST be equal to the > length of the prime modulus over which the exponentiation was > performed, prepending zero bits to the value if necessary. >=20 > Why such a MUST? Does it make sense for "groups" which are not MODP? >=20 > Regards >=20 > Francis.Dupont@point6.net _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec