From ipsec-bounces@ietf.org Sat Apr 01 02:48:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPapd-0001Gd-Sf; Sat, 01 Apr 2006 02:47:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPapc-0001FS-Sk for ipsec@ietf.org; Sat, 01 Apr 2006 02:47:36 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPapZ-0000wS-Fs for ipsec@ietf.org; Sat, 01 Apr 2006 02:47:36 -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 k317lTKX005792; Sat, 1 Apr 2006 09:47:29 +0200 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 k317lQ0X005788; Sat, 1 Apr 2006 09:47:26 +0200 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 k317lPih089559; Sat, 1 Apr 2006 09:47:25 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604010747.k317lPih089559@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Charlie Kaufman Subject: Re: [Ipsec] short question about KE format in IKEv2 In-reply-to: Your message of Thu, 30 Mar 2006 23:32:18 -0800. Date: Sat, 01 Apr 2006 09:47:25 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 In your previous mail you wrote: The text may have to be clarified for groups that are not MODP. The reason for the MUST is to save implementers some work. There is probably an equivalent problem with ECC Diffie-Hellman - if the ECC public number is thought of as an integer, some crypto libraries might truncate it. Mathematically, I believe the ECC public number is a bit string rather than an integer, so it might be "obvious" that an implementation MUST always send a KE value whose length is the largest size possible given the negotiated ECC group. => if I understand well, in fact the MUST should be in the group definitions and not in the KE payload one as the internal format and associated constraints (including mandatory padding) is per group and not generic. Thanks Francis.Dupont@point6.net _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Apr 01 03:01:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPb3R-00074H-Ds; Sat, 01 Apr 2006 03:01:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPb3Q-00074C-Lm for ipsec@ietf.org; Sat, 01 Apr 2006 03:01:52 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPb3P-0001Sq-8b for ipsec@ietf.org; Sat, 01 Apr 2006 03:01:52 -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 k3181oD6006352; Sat, 1 Apr 2006 10:01:50 +0200 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 k3181mCO006346; Sat, 1 Apr 2006 10:01:48 +0200 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 k3181lxi089621; Sat, 1 Apr 2006 10:01:48 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200604010801.k3181lxi089621@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Ipsec] short question about KE format in IKEv2 In-reply-to: Your message of Fri, 31 Mar 2006 14:29:10 +0300. Date: Sat, 01 Apr 2006 10:01:47 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 In your previous mail you wrote: 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. => you confirm me in my opinion the length and the padding requirement are in fact parts of the group definitions. Thanks Francis.Dupont@point6.net _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Apr 03 02:41:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQIhr-0001v6-1k; Mon, 03 Apr 2006 02:38:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQIhk-0001rc-MA for ipsec@ietf.org; Mon, 03 Apr 2006 02:38:24 -0400 Received: from med3.minerva.com ([192.88.236.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQIhj-0000lq-BT for ipsec@ietf.org; Mon, 03 Apr 2006 02:38:24 -0400 Received: from minerva.com by med3.minerva.com ; Sun, 2 Apr 2006 22:52 PST Received: from feroz ([192.88.236.25]) by avatar.minerva.com (sFSRV.0b5 2/27/06) with ESMTP id 004E61W; Sun, 2 Apr 2006 23:38:10 -0700 From: "Greg Bailey" To: Date: Sun, 2 Apr 2006 23:38:09 -0700 Organization: ATHENA Programming, Inc. Message-ID: <04ad01c656e9$2d5d8470$19ec58c0@minerva.com> MIME-Version: 1.0 charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: Thread-Index: AcZMbFUUj94f5K8dT76jnNif+79zBwIJzk/AAAhpxpAAjLX0cA== Content-Type: text/plain; charset="US-ASCII" Content-Length: 1647 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Ipsec] Status of ipsec-wit.antd.nist.gov IPSec tester 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 Help! I am trying to use the venerable IPSec tester kindly maintained by NIST at http://ipsec-wit.antd.nist.gov/ - but it appears to be broken. I have sent messages to NIST during the past two months but have been unable to contact anyone who is responsible for this system. Please help me contact someone who might be able to help. The internal error message from the tester appears below. Thanks in advance! Greg Bailey | ATHENA Programming, Inc | 503-621-3461 | ---------------- | 19330 NW Sauvie Island Rd | fax DOWN | greg@minerva.com | Portland, OR 97231-1315 | =============================================== Directive: Expect: SUCCESSFUL NEGOTIATION Native:plutoplus -p 500 -d 192.88.236.19 -b 2 -b 4 -i -e 2 -a 2 2>&1 ISAKMP/IKE has the following parameters: Role : INITIATOR Authentication : PRESHARED Group number : 1 ISAKMP SA algorithms (enc/hash) : DES_CBC(2)/MD5(2) IPsec ESP algorithm : DES (2) With authentication algorithm : MD5 (1) PFS : NO Replay Protection : YES Encryption IV length : 8 bytes Encryption key length: 8 bytes (64 bits) Mode : TRANSPORT Port # : 500 DEFAULT Oakley SA life duration : 86400 seconds DEFAULT IPsec SA life duration : 28800 seconds DEFAULT IPsec SA life duration : 32767 kbytes ******************** STARTING ******************* STARTING ******************** ***Error: write() kernelfd_sav (ike) failed in kernel_unregister Error: Unexpected Result Occurred =============================================== _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 04 08:23:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkY2-0007Xi-K8; Tue, 04 Apr 2006 08:22:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkY0-0007Xd-RM for ipsec@ietf.org; Tue, 04 Apr 2006 08:22:12 -0400 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 1FQkXx-0002rY-Bz for ipsec@ietf.org; Tue, 04 Apr 2006 08:22:12 -0400 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.5.20060308/8.12.10) with ESMTP id k34CM7YH025429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Apr 2006 15:22:07 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.5.20060308/8.12.11) id k34CM5xQ010364; Tue, 4 Apr 2006 15:22:05 +0300 (EEST) 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: <17458.25837.559125.769859@fireball.acr.fi> Date: Tue, 4 Apr 2006 15:22:05 +0300 From: Tero Kivinen To: Russ Housley Subject: [Ipsec] IKEv1 Security Considerations In-Reply-To: <7.0.0.16.2.20060329193457.02cd98e8@vigilsec.com> References: <7.0.0.16.2.20060329193457.02cd98e8@vigilsec.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 8 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Russ Housley writes: > 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? Usually none. There are quite a many people who do not really agree on that text. I do not think entropy really get consumed, but of course the value of breaking that one Diffie-Hellman increases when more and more keying material is derived from it. In most implementations IKE SAs do have lifetime that is around few hours (from 4-8 hours or so), and using gigabit link with 3DES means you need to rekey avery few minutes, which would mean that you would be doing around 50 quick mode exchanges before the IKE SA expires. The 50 unknown keying materials generated from the same Diffie-Hellman secret, should yet give any way to crack that Diffie-Hellman itself. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 04 11:36:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnZU-0006bj-Hg; Tue, 04 Apr 2006 11:35:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnZS-0006TB-D5 for ipsec@ietf.org; Tue, 04 Apr 2006 11:35:54 -0400 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQnZS-0003eE-5a for ipsec@ietf.org; Tue, 04 Apr 2006 11:35:54 -0400 Received: (qmail 21120 invoked by uid 0); 4 Apr 2006 15:35:50 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (129.6.193.7) by woodstock.binhost.com with SMTP; 4 Apr 2006 15:35:50 -0000 Message-Id: <7.0.0.16.2.20060404113442.05735450@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 04 Apr 2006 11:35:15 -0400 To: Tero Kivinen From: Russ Housley Subject: Re: [Ipsec] IKEv1 Security Considerations In-Reply-To: <17458.25837.559125.769859@fireball.acr.fi> References: <7.0.0.16.2.20060329193457.02cd98e8@vigilsec.com> <17458.25837.559125.769859@fireball.acr.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 I agree with your words, but it is probably not worth the effort to update this paragraph. Russ At 08:22 AM 4/4/2006, Tero Kivinen wrote: >Russ Housley writes: > > 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? > >Usually none. > >There are quite a many people who do not really agree on that text. I >do not think entropy really get consumed, but of course the value of >breaking that one Diffie-Hellman increases when more and more keying >material is derived from it. > >In most implementations IKE SAs do have lifetime that is around few >hours (from 4-8 hours or so), and using gigabit link with 3DES means >you need to rekey avery few minutes, which would mean that you would >be doing around 50 quick mode exchanges before the IKE SA expires. >The 50 unknown keying materials generated from the same Diffie-Hellman >secret, should yet give any way to crack that Diffie-Hellman itself. >-- >kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 05 15:03:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDHu-0000C8-Ui; Wed, 05 Apr 2006 15:03:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDHt-0000B8-9W for ipsec@ietf.org; Wed, 05 Apr 2006 15:03:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRDHr-0004v8-Tm for ipsec@ietf.org; Wed, 05 Apr 2006 15:03:29 -0400 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k35J3Q1T037155 for ; Wed, 5 Apr 2006 12:03:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 5 Apr 2006 11:58:37 -0700 To: IPsec WG From: The IESG (by way of Paul Hoffman) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ipsec] Last Call: 'IKE and IKEv2 Authentication Using ECDSA' to Proposed Standard 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 IESG has received a request from an individual submitter to consider the following document: - 'IKE and IKEv2 Authentication Using ECDSA' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-05-03. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-05.txt Also, this IPR disclosure may be of inerest https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=695 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 05 17:59:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRG1g-00082O-I1; Wed, 05 Apr 2006 17:58:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRG1f-00082E-Cu for ipsec@ietf.org; Wed, 05 Apr 2006 17:58:55 -0400 Received: from servfail.adelman.com ([198.137.202.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRG1d-00085W-Uo for ipsec@ietf.org; Wed, 05 Apr 2006 17:58:55 -0400 Received: from [69.12.142.224] ([69.12.142.224]) by ServFail.Adelman.COM via Internet ; Wed, 5 Apr 2006 14:58:52 PDT In-Reply-To: <7.0.0.16.2.20060404113442.05735450@vigilsec.com> References: <7.0.0.16.2.20060329193457.02cd98e8@vigilsec.com> <17458.25837.559125.769859@fireball.acr.fi> <7.0.0.16.2.20060404113442.05735450@vigilsec.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6E5C9D51-2064-4E5E-A9A8-F3590B0B01A2@electric-loft.org> Content-Transfer-Encoding: 7bit From: Derrell Piper Subject: Re: [Ipsec] IKEv1 Security Considerations Date: Wed, 5 Apr 2006 14:58:52 -0700 To: Russ Housley X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipsec@ietf.org, Tero Kivinen 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 I can't imagine it could be. I mean, it's completely dependent on the size of your pipe. What would be the right answer for a 1.5Mb branch office isn't right for a gigabit ISP. Practically speaking, expiring your IKE SAs every 4-8 hours is a reasonable built-in default, which is what most vendors are doing and nearly every implementation also lets you configure that limit anyway. So I don't see that there's a problem we need to solve by amending the RFC even if we could agree on what that number should be... :-) Derrell On Apr 4, 2006, at 8:35 AM, Russ Housley wrote: > I agree with your words, but it is probably not worth the effort to > update this paragraph. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 06 09:54:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRUw8-0006mO-HS; Thu, 06 Apr 2006 09:54:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRUw7-0006mG-6f; Thu, 06 Apr 2006 09:54:11 -0400 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 1FRUw5-0000qL-EK; Thu, 06 Apr 2006 09:54:11 -0400 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.5.20060308/8.12.10) with ESMTP id k36Ds73C018657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Apr 2006 16:54:07 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.5.20060308/8.12.11) id k36Ds6je010377; Thu, 6 Apr 2006 16:54:06 +0300 (EEST) 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: <17461.7550.267125.637618@fireball.acr.fi> Date: Thu, 6 Apr 2006 16:54:06 +0300 From: Tero Kivinen To: IPsec WG Subject: [Ipsec] Last Call: 'IKE and IKEv2 Authentication Using ECDSA' to Proposed Standard In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 41 min X-Total-Time: 50 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: iesg@ietf.org, defu@orion.ncsc.mil 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 IESG (by way of Paul Hoffman) writes: > - 'IKE and IKEv2 Authentication Using ECDSA' > as a Proposed Standard The draft-ietf-ipsec-ike-auth-ecdsa-05.txt claims in section "3. Specifying ECDSA within IKE and IKEv2" that there is IANA allocated number for ECDSA, but that is not true for IKEv2. There is IKEv1 number allocated for it, but the IKEv2 registry (http://www.iana.org/assignments/ikev2-parameters) does not have any number allocated for ECDSA. Note, that IKEv1 and IKEv2 registries are separate, and numbers needs to be allocated from both in case it is required to be used with both versions. The correct registry to allocate that number from the IKEv2 registries is the "IKEv2 Authentication Method" registry, and the numbers in that registry are not same as the ones in the IKEv1 "IPSEC Authentication Methods" registry. I am not sure wheter I understand the table listing the IKEv1 IANA registry value, Diffie-Hellman groups and Hash functions in section 3. Is it so that that group and that hash function is used to calculate the signature itself, or is it so that same groups must also be used in the IKE (i.e Diffie-Hellman group of the IKE and hash function used in the IKE)? >From the later paragraphs it seems that those Diffie-Hellman groups and Hash functions are only used when generating and verifying the signature, and the IKE itself can use different Diffie-Hellman group and different hash function. I think there should be some more text explaining this fact, and the numbers in the brackets refering to the IKEv1 allocated IANA identifiers should be removed, as they simply confuse reader. As I explained earlier IKEv2 has separate registry for those things too, and IKEv2 do not even have hash function registry at all (it has registries for Pseudo-random Function and for Integrity Algorithms, but not for hash functions). The IANA Considerations section is quite vague which registries should be updated, i.e. it does not for example list at all the actual name to put to the registry and does not list IKEv1 and IKEv2 registries separately. The test vectors assume that number 9, 10, are 11, are going to be allocated from the IKEv2 registries too for those, but I think it would be much more logical to allocate next free numbers i.e. 4, 5, and 6. Actually it would be much better not to refere those methods as numbers at all but give them names, and put the mapping from numbers to names in the IANA registries. So I propose following changes: ---------------------------------------------------------------------- Change: The IANA-assigned attribute number for authentication using generic ECDSA is 8 (see [IANA]), but the parameters and associated hash functions are not specified. The document defines the following authentication algorithms along with their anticipated IANA attribute numbers. Digital Diffie- IANA Signature Hellman Hash Value Algorithm Group Function ----- --------- ------------ ------------- 9 ECDSA P-256 [19] SHA-256 [4] 10 ECDSA P-384 [20] SHA-384 [5] 11 ECDSA P-521 [21] SHA-512 [6] The numbers in brackets are the IANA identifiers for the Diffie- Hellman groups and the hash functions. to There is IANA-assigned attribute number for authentication using generic ECDSA for IKEv1, but the parameters and associated hash functions are not specified. The document defines the following authentication algorithms along with their anticipated IANA attribute numbers. Authentication Digital Diffie- Method Signature Hellman Hash Name Algorithm Group Function ----- --------- ----- -------- ECDSA-P-256-SHA-256 ECDSA P-256 SHA-256 ECDSA-P-384-SHA-384 ECDSA P-384 SHA-384 ECDSA-P-512-SHA-512 ECDSA P-512 SHA-512 Those parameters are used when calculating the signature, the Diffie-Hellman group and hash functions are negotiated separately when used in the IKE. ---------------------------------------------------------------------- I.e. removed all references to IANA numbers from here, added names for the authentication methods, fixed P-521 to P-512 also as I assume P-521 is a typo, and added comment that parameters are only for ECDSA signature calculation, they do not replace Diffie-Hellman / Hash function etc negotiation of IKE. ---------------------------------------------------------------------- Change: 5. IANA Considerations Before this document can become an RFC, it is required that IANA update its registry of IKE authentication methods in [IANA] to include the three options defined in Section 3 of this document. to 5. IANA Considerations This document adds 3 parameters to the 2 existing registries. Changes to "Internet Key Exchange (IKE) Attributes" (http://www.iana.org/assignments/ipsec-registry) "IPSEC Authentication Methods" registry: Value Method ----- ------ (IANA-TBA1) ECDSA with P-256 and SHA-256 (ECDSA-P-256-SHA-256) (IANA-TBA2) ECDSA with P-384 and SHA-384 (ECDSA-P-384-SHA-384) (IANA-TBA3) ECDSA with P-512 and SHA-512 (ECDSA-P-512-SHA-512) Changes to "Internet Key Exchange Version 2 (IKEv2) Parameters" (http://www.iana.org/assignments/ikev2-parameters) "IKEv2 Authentication Method" registry: Value Method ----- ------ (IANA-TBA4) ECDSA with P-256 and SHA-256 (ECDSA-P-256-SHA-256) (IANA-TBA5) ECDSA with P-384 and SHA-384 (ECDSA-P-384-SHA-384) (IANA-TBA6) ECDSA with P-512 and SHA-512 (ECDSA-P-512-SHA-512) ---------------------------------------------------------------------- Change 6.1 Authentication Method 9 The parameters for Diffie-Hellman group 19 are to 6.1 Authentication Method ECDSA-P-256-SHA-256 The parameters for Diffie-Hellman group P-256 are ---------------------------------------------------------------------- and also change in section 6.1 last full payload example from 00000048 00090000 CB28E099 9B9C7715 FD0A80D8 E47A7707 9716CBBF 917DD72E 97566EA1 C066957C 86FA3BB4 E26CAD5B F90B7F81 899256CE 7594BB1E A0C89212 748BFF3B 3D5B0315 to 00000048 (IANA-TBA4)0000 CB28E099 9B9C7715 FD0A80D8 E47A7707 9716CBBF 917DD72E 97566EA1 C066957C 86FA3BB4 E26CAD5B F90B7F81 899256CE 7594BB1E A0C89212 748BFF3B 3D5B0315 {The IANA-TBA4 is replaced with the actual value of the number assigned by IANA for the IANA-TBA4 in hexadesimal format for 16-bit field. This note is removed from the final RFC} ---------------------------------------------------------------------- And similar changes to 6.2, and 6.3. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 12 01:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTXx1-0003pF-3Q; Wed, 12 Apr 2006 01:31:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTXsc-00032R-Bu for ipsec@ietf.org; Wed, 12 Apr 2006 01:27:02 -0400 Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTXjP-00068E-Bt for ipsec@ietf.org; Wed, 12 Apr 2006 01:17:40 -0400 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id k3C5HN232605 for ; Wed, 12 Apr 2006 10:47:28 +0530 To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Allan.DSouza@flextronicssoftware.com Date: Wed, 12 Apr 2006 10:44:56 +0530 X-MIMETrack: S/MIME Sign by Notes Client on Allan Prakash DSouza/BLR/HSS(Release 6.5.1|January 21, 2004) at 04/12/2006 10:47:18 AM, Serialize by Notes Client on Allan Prakash DSouza/BLR/HSS(Release 6.5.1|January 21, 2004) at 04/12/2006 10:47:18 AM, Serialize complete at 04/12/2006 10:47:18 AM, S/MIME Sign failed at 04/12/2006 10:47:18 AM: The cryptographic key was not found, Serialize by Router on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 04/12/2006 10:47:01 AM, Serialize complete at 04/12/2006 10:47:01 AM X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Ipsec] Hi 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="===============0158775120==" Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0158775120== Content-Type: multipart/alternative; boundary="=_alternative 001D0CDA6525714E_=" This is a multipart message in MIME format. --=_alternative 001D0CDA6525714E_= Content-Type: text/plain; charset="US-ASCII" Hi, Goodmorning....I am a new member to this mailing list. I am doing project on IKEV2 in UMA which is implemented on GSM n/w's. Can someone help me or provide the useful links about how the IKE2 keys are exchanged and mutual authentication takes place in UMA technology?? I am going thru 3GPP spec...But still detailed view about IKEV2 is required. I am very greatful, if anyone favour me in this regard as soon as possible. Regards, Allan D'Souza *********************** FSS-Unclassified *********************** --=_alternative 001D0CDA6525714E_= Content-Type: text/html; charset="US-ASCII"
Hi,
Goodmorning....I am a new member to this mailing list.
I am doing project on IKEV2 in UMA which is implemented on GSM n/w's.
Can someone help me or provide the useful links about how the IKE2 keys are exchanged and mutual authentication takes place in UMA technology??
I am going thru 3GPP spec...But still detailed view about IKEV2 is required.
I am very greatful, if anyone favour me in this regard as soon as possible.

Regards,
Allan D'Souza


***********************  FSS-Unclassified   *********************** --=_alternative 001D0CDA6525714E_=-- --===============0158775120== 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 --===============0158775120==-- From ipsec-bounces@ietf.org Wed Apr 12 12:55:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTid0-0000nK-Ob; Wed, 12 Apr 2006 12:55:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTicz-0000nF-PB for ipsec@ietf.org; Wed, 12 Apr 2006 12:55:37 -0400 Received: from xproxy.gmail.com ([66.249.82.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTicx-0004hn-H0 for ipsec@ietf.org; Wed, 12 Apr 2006 12:55:37 -0400 Received: by xproxy.gmail.com with SMTP id s12so1108507wxc for ; Wed, 12 Apr 2006 09:55:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Z7tuxjaKmBOxaZB/QBMW+U/KWEUso89MYSQVTWITEBDEv/sgviR6CUg7GVuVK9b82XCm1l03r9OK6VoWFlg7dboLpX341oHr8Pz/MaF+qi91WrEOYtAoQuj6qQ3lpr8+rSOdEJZHHeZKGeoGCNOSBMcAxPJkZQRi2KZbatbidLQ= Received: by 10.70.52.6 with SMTP id z6mr4188086wxz; Wed, 12 Apr 2006 09:55:34 -0700 (PDT) Received: by 10.70.34.18 with HTTP; Wed, 12 Apr 2006 09:55:34 -0700 (PDT) Message-ID: <77ead0ec0604120955o4e613a5ci176503e3208d916b@mail.gmail.com> Date: Wed, 12 Apr 2006 09:55:34 -0700 From: "Vishwas Manral" To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Ipsec] RFC4305 Errata draft 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="===============1965389522==" Errors-To: ipsec-bounces@ietf.org --===============1965389522== Content-Type: multipart/alternative; boundary="----=_Part_6427_30330176.1144860934907" ------=_Part_6427_30330176.1144860934907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi folks, I have written a draft http://www.ietf.org/internet-drafts/draft-manral-ipsec-rfc4305-errata-00.tx= twhich lists the errata in the RFC4305. I think the draft is necessary(instead of just an errata) because the changes relate mostly chaging a few MUST's to MAY(which is a much bigger change). I think we need to close this draft soon, as I can see the error being propagated to other RFC's e.g. http://www.rfc-editor.org/rfc/rfc4294.txt . And although I informed the author of the RFC it was already too late. If w= e want we can rewrite the RFC with the changes incorporated(and additional algorithms CMAC etc). Any comments would be appriciated. Thanks, Vishwas ------=_Part_6427_30330176.1144860934907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi folks,

I have written a draft http://www.ietf.org/internet-drafts/draft-manral-ipsec-rfc430= 5-errata-00.txt which lists the errata in the RFC4305.

I think the draft is necessary(instead of just an errata) because the changes relate mostly chaging a few MUST's to MAY(which is a much bigger change).

I think we need to close this draft soon, as I can see the error being propagated to other RFC's e.g. http://www.rfc-editor= .org/rfc/rfc4294.txt . And although I informed the author of the RFC it was already too late. If we want we can rewrite the RFC with the changes incorporated(and additional algorithms CMAC etc).

Any comments would be appriciated.

Thanks,
Vishwas

------=_Part_6427_30330176.1144860934907-- --===============1965389522== 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 --===============1965389522==-- From ipsec-bounces@ietf.org Thu Apr 13 15:24:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU7QC-0002hI-J5; Thu, 13 Apr 2006 15:24:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU7QB-0002hD-1q for ipsec@ietf.org; Thu, 13 Apr 2006 15:24:03 -0400 Received: from mxout5.netvision.net.il ([194.90.9.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU7Q8-00084S-Bb for ipsec@ietf.org; Thu, 13 Apr 2006 15:24:03 -0400 Received: from [192.168.0.70] ([217.132.158.36]) by mxout5.netvision.net.il (Sun Java System Messaging Server 6.1 HotFix 0.11 (built Jan 28 2005)) with ESMTP id <0IXO00MLIDVY62G0@mxout5.netvision.net.il> for ipsec@ietf.org; Thu, 13 Apr 2006 22:23:58 +0300 (IDT) Date: Thu, 13 Apr 2006 22:24:03 +0300 From: Yoav Nir Subject: Re: [Ipsec] RFC4305 Errata draft In-reply-to: <77ead0ec0604120955o4e613a5ci176503e3208d916b@mail.gmail.com> To: Vishwas Manral Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.749.3) References: <77ead0ec0604120955o4e613a5ci176503e3208d916b@mail.gmail.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: , Content-Type: multipart/mixed; boundary="===============0653809994==" Errors-To: ipsec-bounces@ietf.org --===============0653809994== Content-type: multipart/alternative; boundary="Boundary_(ID_wepi4+kpn9YYkKbTjbZs/g)" --Boundary_(ID_wepi4+kpn9YYkKbTjbZs/g) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT This may be a stupid question, but why an errata draft that updates 4305 instead of a new draft that obsoletes 4305? On Apr 12, 2006, at 7:55 PM, Vishwas Manral wrote: > Hi folks, > > I have written a draft http://www.ietf.org/internet-drafts/draft- > manral-ipsec-rfc4305-errata-00.txt which lists the errata in the > RFC4305. > > I think the draft is necessary(instead of just an errata) because > the changes relate mostly chaging a few MUST's to MAY(which is a > much bigger change). > > I think we need to close this draft soon, as I can see the error > being propagated to other RFC's e.g. http://www.rfc-editor.org/rfc/ > rfc4294.txt . And although I informed the author of the RFC it was > already too late. If we want we can rewrite the RFC with the > changes incorporated(and additional algorithms CMAC etc). > > Any comments would be appriciated. > > Thanks, > Vishwas > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_wepi4+kpn9YYkKbTjbZs/g) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT This may be a stupid question, but why an errata draft that updates 4305 instead of a new draft that obsoletes 4305?

On Apr 12, 2006, at 7:55 PM, Vishwas Manral wrote:

Hi folks,

I have written a draft http://www.ietf.org/internet-drafts/draft-manral-ipsec-rfc4305-errata-00.txt which lists the errata in the RFC4305.

I think the draft is necessary(instead of just an errata) because the changes relate mostly chaging a few MUST's to MAY(which is a much bigger change).

I think we need to close this draft soon, as I can see the error being propagated to other RFC's e.g. http://www.rfc-editor.org/rfc/rfc4294.txt . And although I in RFC it was already too late. If we want we can rewrite the RFC with the changes incorporated(and additional algorithms CMAC etc).

Any comments would be appriciated.

Thanks,
Vishwas

_______________________________________________
Ipsec mailing list

--Boundary_(ID_wepi4+kpn9YYkKbTjbZs/g)-- --===============0653809994== 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 --===============0653809994==-- From ipsec-bounces@ietf.org Thu Apr 13 15:26:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU7Sh-0004oH-EE; Thu, 13 Apr 2006 15:26:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU7Sf-0004o2-UH for ipsec@ietf.org; Thu, 13 Apr 2006 15:26:37 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU7Se-0008Av-Kq for ipsec@ietf.org; Thu, 13 Apr 2006 15:26:37 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3DJQV3d023283 for ; Thu, 13 Apr 2006 13:26:36 -0600 (MDT) 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 k3DJQTdc022474 for ; Thu, 13 Apr 2006 13:26:30 -0600 (MDT) 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 k3DJQTTH022957; Thu, 13 Apr 2006 14:26:29 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3DJQSIh022956; Thu, 13 Apr 2006 14:26:28 -0500 (CDT) Date: Thu, 13 Apr 2006 14:26:28 -0500 From: Nicolas Williams To: Yoav Nir Subject: Re: [Ipsec] RFC4305 Errata draft Message-ID: <20060413192627.GB22906@binky.Central.Sun.COM> Mail-Followup-To: Yoav Nir , Vishwas Manral , ipsec@ietf.org References: <77ead0ec0604120955o4e613a5ci176503e3208d916b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Thu, Apr 13, 2006 at 10:24:03PM +0300, Yoav Nir wrote: > This may be a stupid question, but why an errata draft that updates > 4305 instead of a new draft that obsoletes 4305? Errata updates nothing, they're not normative. But errata fill a void in between issuance of updates. Also, a new RFC that corrects errors in one or more older RFCs need not obsolete them. Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 13 15:33:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU7ZS-0008Vd-MM; Thu, 13 Apr 2006 15:33:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU7ZR-0008VO-Ar for ipsec@ietf.org; Thu, 13 Apr 2006 15:33:37 -0400 Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU7ZQ-0008M8-4Y for ipsec@ietf.org; Thu, 13 Apr 2006 15:33:37 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id k3DJXZko026853 for ; Thu, 13 Apr 2006 15:33:35 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id k3DJXZ3L026848; Thu, 13 Apr 2006 15:33:35 -0400 Received: from pkoning.equallogic.com ([172.16.1.169]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 15:33:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17470.42893.962461.184839@gargle.gargle.HOWL> Date: Thu, 13 Apr 2006 15:33:33 -0400 From: Paul Koning To: vishwas.ietf@gmail.com Subject: Re: [Ipsec] RFC4305 Errata draft References: <77ead0ec0604120955o4e613a5ci176503e3208d916b@mail.gmail.com> X-Mailer: VM 7.17 under 21.5 (beta23) "daikon" XEmacs Lucid X-OriginalArrivalTime: 13 Apr 2006 19:33:35.0289 (UTC) FILETIME=[27D42A90:01C65F31] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 If you're going to change the required status of ESP NULL authentication -- which I support -- it would make sense to change it all the way to SHOULD NOT. The footnote about SHA-1 collisions also should be added to section 3.1.1. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 13 16:27:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU8Ot-0001Lh-V0; Thu, 13 Apr 2006 16:26:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU8Ot-0001Lc-BH for ipsec@ietf.org; Thu, 13 Apr 2006 16:26:47 -0400 Received: from xproxy.gmail.com ([66.249.82.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU8Or-0002tw-UK for ipsec@ietf.org; Thu, 13 Apr 2006 16:26:47 -0400 Received: by xproxy.gmail.com with SMTP id s12so1314449wxc for ; Thu, 13 Apr 2006 13:26:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=jr7kymFgq2guFvuNUJhNU+ys3AS/cmUwkzqCj4OIVqCx+EFievJtlTYp3r1NTlD7CJogw7QBjzwSqDUXmXGuyfTprKIS9KLt1eir5F58c0h8xt3TmLEOTJFr6K/BW6ulR90iComQSSji2BWxrTY5Fz4fJfhjHaTNm6AO1hATXfk= Received: by 10.70.38.7 with SMTP id l7mr1119280wxl; Thu, 13 Apr 2006 13:26:45 -0700 (PDT) Received: by 10.70.34.18 with HTTP; Thu, 13 Apr 2006 13:26:45 -0700 (PDT) Message-ID: <77ead0ec0604131326p2af7298ex7adbfaabf637788f@mail.gmail.com> Date: Thu, 13 Apr 2006 13:26:45 -0700 From: "Vishwas Manral" To: "Paul Koning" Subject: Re: [Ipsec] RFC4305 Errata draft In-Reply-To: <17470.42893.962461.184839@gargle.gargle.HOWL> MIME-Version: 1.0 References: <77ead0ec0604120955o4e613a5ci176503e3208d916b@mail.gmail.com> <17470.42893.962461.184839@gargle.gargle.HOWL> X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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: , Content-Type: multipart/mixed; boundary="===============1981409741==" Errors-To: ipsec-bounces@ietf.org --===============1981409741== Content-Type: multipart/alternative; boundary="----=_Part_25688_31091354.1144960005549" ------=_Part_25688_31091354.1144960005549 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Paul, That is an interesting point. The current draft makes the ESP NULL authentication to MAY, because RFC4303 and I guess RFC4301 state that - confidentiality-only (MAY be supported) Do you think it is advisable to make that to SHOULD NOT? Thanks, Vishwas On 4/13/06, Paul Koning wrote: > > If you're going to change the required status of ESP NULL > authentication -- which I support -- it would make sense to change it > all the way to SHOULD NOT. > > The footnote about SHA-1 collisions also should be added to section > 3.1.1. > > paul > > ------=_Part_25688_31091354.1144960005549 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Paul,

That is an interesting point. The current draft makes the ESP NULL authentication to MAY, because RFC4303 and I guess RFC4301 state that
     - confidentiality-only (MAY be supported)

Do you think it is advisable to make that to SHOULD NOT?

Thanks,
Vishwas

On 4/13/06, Paul Koning <pkoning@equallogic.com> wrote:
If you're going to change the required status of ESP NULL
authentication= -- which I support -- it would make sense to change it
all the way to S= HOULD NOT.

The footnote about SHA-1 collisions also should be added = to section
3.1.1.

       paul


------=_Part_25688_31091354.1144960005549-- --===============1981409741== 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 --===============1981409741==-- From ipsec-bounces@ietf.org Thu Apr 13 16:29:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU8Ru-0002Ud-Hb; Thu, 13 Apr 2006 16:29:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU8Rt-0002UY-Mr for ipsec@ietf.org; Thu, 13 Apr 2006 16:29:53 -0400 Received: from xproxy.gmail.com ([66.249.82.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU8Rs-0002y0-Dp for ipsec@ietf.org; Thu, 13 Apr 2006 16:29:53 -0400 Received: by xproxy.gmail.com with SMTP id s12so1314869wxc for ; Thu, 13 Apr 2006 13:29:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ipFtO7IagYSLBnnmiptScjJ348bzFTQhCmvaNOV5ETxACCndTO/Q0WQuz3qqYphn7VqkxzhjVU8ShXdQx8VtXzXt6twkicneQ4UFSwSvrlZP2ckf31orNpjb0aUCAksQ8osIg8MrlBeGPUfVNaO0/UYe5ni4cswvlhoc1xIX9uA= Received: by 10.70.18.14 with SMTP id 14mr202116wxr; Thu, 13 Apr 2006 13:29:52 -0700 (PDT) Received: by 10.70.34.18 with HTTP; Thu, 13 Apr 2006 13:29:52 -0700 (PDT) Message-ID: <77ead0ec0604131329j3d0d351dsfa9a7f62fbaa12a5@mail.gmail.com> Date: Thu, 13 Apr 2006 13:29:52 -0700 From: "Vishwas Manral" To: "Yoav Nir" Subject: Re: [Ipsec] RFC4305 Errata draft In-Reply-To: MIME-Version: 1.0 References: <77ead0ec0604120955o4e613a5ci176503e3208d916b@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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: , Content-Type: multipart/mixed; boundary="===============0270375556==" Errors-To: ipsec-bounces@ietf.org --===============0270375556== Content-Type: multipart/alternative; boundary="----=_Part_25732_8512199.1144960192162" ------=_Part_25732_8512199.1144960192162 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Yaov, You have a good point there. I am ok working on a draft that update's and obsoletes RFC4305 too, if we envision more changes like adding the status of new algorithm's like CMAC i= n the RFC I think that would be the advisable thing to do this. I have mentioned this in the previous mail of mine. Thanks, Vishwas On 4/13/06, Yoav Nir wrote: > > This may be a stupid question, but why an errata draft that updates 4305 > instead of a new draft that obsoletes 4305? > On Apr 12, 2006, at 7:55 PM, Vishwas Manral wrote: > > Hi folks, > > I have written a draft > http://www.ietf.org/internet-drafts/draft-manral-ipsec-rfc4305-errata-00.= txtwhich lists the errata in the RFC4305. > > I think the draft is necessary(instead of just an errata) because the > changes relate mostly chaging a few MUST's to MAY(which is a much bigger > change). > > I think we need to close this draft soon, as I can see the error being > propagated to other RFC's e.g. http://www.rfc-editor.org/rfc/rfc4294.txt = . > And although I in RFC it was already too late. If we want we can rewrite = the > RFC with the changes incorporated(and additional algorithms CMAC etc). > > > Any comments would be appriciated. > > Thanks, > Vishwas > ------=_Part_25732_8512199.1144960192162 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Yaov,

You have a good point there.

I am ok working on a draft that update's and obsoletes RFC4305 too, if we envision more changes like adding the status of new algorithm's like CMAC in the RFC I think that would be the advisable thing to do this. I have mentioned this in the previous mail of mine.

Thanks,
Vishwas

On 4/13/06, Yoav Nir <yn= ir@netvision.net.il> wrote:
This may be a stupid question, but why an er= rata draft that updates 4305 instead of a new draft that obsoletes 4305?
On A= pr 12, 2006, at 7:55 PM, Vishwas Manral wrote:

Hi= folks,

I have written a draft http://www.ietf.org/internet-drafts/draft-manral-ipsec-rfc4305-errata-00.tx= t which lists the errata in the RFC4305.

I think the draft is necessary(instead of just an errata) because the changes relate mostly chaging a few MUST's to MAY(which is a much bigger change).

I thin= k we need to close this draft soon, as I can see the error being propagated= to other RFC's e.g. http://www.rfc-editor.org/rfc/rfc4294.txt . And although I in RFC it was already too late. If we want we can rewrite the RFC with the changes incorporated(and additional algorithms CMAC etc).


Any comments would be appr= iciated.

Thanks,
Vishwas

------=_Part_25732_8512199.1144960192162-- --===============0270375556== 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 --===============0270375556==-- From ipsec-bounces@ietf.org Thu Apr 13 16:55:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU8pr-0002xp-DO; Thu, 13 Apr 2006 16:54:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU8pq-0002xk-18 for ipsec@ietf.org; Thu, 13 Apr 2006 16:54:38 -0400 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 1FU8pp-0003NQ-VX for ipsec@ietf.org; Thu, 13 Apr 2006 16:54:38 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FU8pn-0000gN-9g for ipsec@ietf.org; Thu, 13 Apr 2006 16:54:37 -0400 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 k3DKsUNb065601; Thu, 13 Apr 2006 13:54:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <17470.42893.962461.184839@gargle.gargle.HOWL> References: <77ead0ec0604120955o4e613a5ci176503e3208d916b@mail.gmail.com> <17470.42893.962461.184839@gargle.gargle.HOWL> Date: Thu, 13 Apr 2006 13:54:31 -0700 To: Paul Koning , vishwas.ietf@gmail.com From: Paul Hoffman Subject: Re: [Ipsec] RFC4305 Errata draft Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.2 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 At 3:33 PM -0400 4/13/06, Paul Koning wrote: >If you're going to change the required status of ESP NULL >authentication -- which I support -- it would make sense to change it >all the way to SHOULD NOT. Then it is not an errata, it is a new protocol. Vishwas: your choice. Do you want to turn these in as errata, or as a full replacement to 4305? If the latter, you should copy RFC 4305 into a new document, make your changes, and add an appendix about what you have changed. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 13 17:10:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU95H-0000dR-Be; Thu, 13 Apr 2006 17:10:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU95F-0000dM-Gs for ipsec@ietf.org; Thu, 13 Apr 2006 17:10:33 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU95B-0003q6-Uh for ipsec@ietf.org; Thu, 13 Apr 2006 17:10:33 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k3DLASK7014947 for ; Thu, 13 Apr 2006 14:10:28 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3DLALce023139 for ; Thu, 13 Apr 2006 15:10:24 -0600 (MDT) 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 k3DLAFEx023033; Thu, 13 Apr 2006 16:10:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3DLAEPk023032; Thu, 13 Apr 2006 16:10:14 -0500 (CDT) Date: Thu, 13 Apr 2006 16:10:14 -0500 From: Nicolas Williams To: Paul Hoffman Subject: Re: [Ipsec] RFC4305 Errata draft Message-ID: <20060413211013.GE22906@binky.Central.Sun.COM> Mail-Followup-To: Paul Hoffman , Paul Koning , vishwas.ietf@gmail.com, ipsec@ietf.org References: <77ead0ec0604120955o4e613a5ci176503e3208d916b@mail.gmail.com> <17470.42893.962461.184839@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipsec@ietf.org, Paul Koning 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 Thu, Apr 13, 2006 at 01:54:31PM -0700, Paul Hoffman wrote: > At 3:33 PM -0400 4/13/06, Paul Koning wrote: > >If you're going to change the required status of ESP NULL > >authentication -- which I support -- it would make sense to change it > >all the way to SHOULD NOT. > > Then it is not an errata, it is a new protocol. > > Vishwas: your choice. Do you want to turn these in as errata, or as a > full replacement to 4305? If the latter, you should copy RFC 4305 > into a new document, make your changes, and add an appendix about > what you have changed. You don't have to obsolete 4305 to make this change, but you can't change RFC2119 language in errata without some evidence that the language you're changing was incorrect in the original, and, anyways, errata are not normative, they are not endorsed by any entity. Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 13 18:05:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU9wO-0002Gg-Ff; Thu, 13 Apr 2006 18:05:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU9wN-0002Em-EK for ipsec@ietf.org; Thu, 13 Apr 2006 18:05:27 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU9wM-0005U5-45 for ipsec@ietf.org; Thu, 13 Apr 2006 18:05:27 -0400 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 k3DM5LEg068830; Thu, 13 Apr 2006 15:05:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <17470.47949.442208.117264@gargle.gargle.HOWL> <20060413211013.GE22906@binky.Central.Sun.COM> References: <77ead0ec0604120955o4e613a5ci176503e3208d916b@mail.gmail.com> <17470.42893.962461.184839@gargle.gargle.HOWL> <17470.47949.442208.117264@gargle.gargle.HOWL> <77ead0ec0604120955o4e613a5ci176503e3208d916b@mail.gmail.com> <17470.42893.962461.184839@gargle.gargle.HOWL> <20060413211013.GE22906@binky.Central.Sun.COM> Date: Thu, 13 Apr 2006 15:05:21 -0700 To: Paul Koning From: Paul Hoffman Subject: Re: [Ipsec] RFC4305 Errata draft Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 At 4:57 PM -0400 4/13/06, Paul Koning wrote: >Is that only when changing from MUST to SHOULD NOT -- and not when >changing from MUST to MAY? Why? The MUST->MAY is clearly indicated by the current text itself. Going to SHOULD NOT is not (regardless of how much we agree on it). --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 13 18:16:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUA6l-0003oV-Qk; Thu, 13 Apr 2006 18:16:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUA6k-0003oQ-LU for ipsec@ietf.org; Thu, 13 Apr 2006 18:16:10 -0400 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 1FU99P-0003tg-IV for ipsec@ietf.org; Thu, 13 Apr 2006 17:14:51 -0400 Received: from sadr.equallogic.com ([66.155.203.134]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FU8qF-0000gk-VA for ipsec@ietf.org; Thu, 13 Apr 2006 16:55:07 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id k3DKt2ko032070 for ; Thu, 13 Apr 2006 16:55:02 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id k3DKt23L032065; Thu, 13 Apr 2006 16:55:02 -0400 Received: from pkoning.equallogic.com ([172.16.1.169]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 16:55:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17470.47781.415283.910357@gargle.gargle.HOWL> Date: Thu, 13 Apr 2006 16:55:01 -0400 From: Paul Koning To: vishwas.ietf@gmail.com Subject: Re: [Ipsec] RFC4305 Errata draft References: <77ead0ec0604120955o4e613a5ci176503e3208d916b@mail.gmail.com> <17470.42893.962461.184839@gargle.gargle.HOWL> <77ead0ec0604131326p2af7298ex7adbfaabf637788f@mail.gmail.com> X-Mailer: VM 7.17 under 21.5 (beta23) "daikon" XEmacs Lucid X-OriginalArrivalTime: 13 Apr 2006 20:55:02.0633 (UTC) FILETIME=[88E9AD90:01C65F3C] X-Spam-Score: -2.6 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 >>>>> "Vishwas" == Vishwas Manral writes: Vishwas> Hi Paul, That is an interesting point. The current draft Vishwas> makes the ESP NULL authentication to MAY, because RFC4303 Vishwas> and I guess RFC4301 state that - confidentiality-only (MAY Vishwas> be supported) Vishwas> Do you think it is advisable to make that to SHOULD NOT? Yes, because of the problems Steve Bellovin documented a number of years ago. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 13 20:54:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUCZn-0001VV-J4; Thu, 13 Apr 2006 20:54:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUCZm-0001VQ-2z for ipsec@ietf.org; Thu, 13 Apr 2006 20:54:18 -0400 Received: from xproxy.gmail.com ([66.249.82.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUCZk-00034H-Gs for ipsec@ietf.org; Thu, 13 Apr 2006 20:54:17 -0400 Received: by xproxy.gmail.com with SMTP id s12so1341236wxc for ; Thu, 13 Apr 2006 17:54:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=iVRGAIfzC5aVnvsqCSJa/q7hxsqAIf4Q9l1/jdsdNl5bmm1X/1JGAogqXTqtqLiTNT/TQQyHkeFqFDdYOyDofPMY3PiDu+qBVOroxLqVUwcA9c9zBwC6vnwLlUZjalxTKeBFIiY2X8D6M3OiRIiClpxfrM8ww4fZOjZuV9vYNYY= Received: by 10.70.18.13 with SMTP id 13mr1363665wxr; Thu, 13 Apr 2006 17:54:16 -0700 (PDT) Received: by 10.70.34.18 with HTTP; Thu, 13 Apr 2006 17:54:16 -0700 (PDT) Message-ID: <77ead0ec0604131754n2394ef9cmfd71210131ea22d0@mail.gmail.com> Date: Thu, 13 Apr 2006 17:54:16 -0700 From: "Vishwas Manral" To: "Paul Hoffman" Subject: Re: [Ipsec] RFC4305 Errata draft In-Reply-To: MIME-Version: 1.0 References: <77ead0ec0604120955o4e613a5ci176503e3208d916b@mail.gmail.com> <17470.42893.962461.184839@gargle.gargle.HOWL> <17470.47949.442208.117264@gargle.gargle.HOWL> <20060413211013.GE22906@binky.Central.Sun.COM> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipsec@ietf.org, Paul Koning 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="===============1946368345==" Errors-To: ipsec-bounces@ietf.org --===============1946368345== Content-Type: multipart/alternative; boundary="----=_Part_866_11255607.1144976056008" ------=_Part_866_11255607.1144976056008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I agree with Paul H. I will put togather another draft and send it across with the diffs with RFC4305. Thanks, Vishwas On 4/13/06, Paul Hoffman wrote: > > At 4:57 PM -0400 4/13/06, Paul Koning wrote: > >Is that only when changing from MUST to SHOULD NOT -- and not when > >changing from MUST to MAY? Why? > > The MUST->MAY is clearly indicated by the current text itself. Going > to SHOULD NOT is not (regardless of how much we agree on it). > > --Paul Hoffman, Director > --VPN Consortium > ------=_Part_866_11255607.1144976056008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,

I agree with Paul H. I will put togather another draft and send it across w= ith the diffs with RFC4305.

Thanks,
Vishwas

On 4/13/06, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
At 4:57 PM -0400 4/13/06, Paul Koning wrote:
>Is that only when chang= ing from MUST to SHOULD NOT -- and not when
>changing from MUST to MA= Y?  Why?

The MUST->MAY is clearly indicated by the curr= ent text itself. Going
to SHOULD NOT is not (regardless of how much we agree on it).

--= Paul Hoffman, Director
--VPN Consortium

------=_Part_866_11255607.1144976056008-- --===============1946368345== 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 --===============1946368345==-- From ipsec-bounces@ietf.org Fri Apr 14 04:03:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUJGy-0002Je-F1; Fri, 14 Apr 2006 04:03:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUJGw-0002JZ-Bb for ipsec@ietf.org; Fri, 14 Apr 2006 04:03:18 -0400 Received: from web38305.mail.mud.yahoo.com ([209.191.125.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FUJGu-0008Ou-Lq for ipsec@ietf.org; Fri, 14 Apr 2006 04:03:18 -0400 Received: (qmail 1172 invoked by uid 60001); 14 Apr 2006 08:03:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ns4z/YjDil3PkzgUS0sdM3EsUxFvPJLd3yPXbpTN02Jntq8MgRMwNLmE73CCsemMPele3z3nGfxIFWOI55eKNR2r7uhTzBr5cM7VJavkkjDzFHM2fkXKunqDo86TSoUUxZk4DigSvHT67Uo1XhvuhnA2oVQvP1lY+DH5Lw0p+5g= ; Message-ID: <20060414080316.1170.qmail@web38305.mail.mud.yahoo.com> Received: from [203.145.155.11] by web38305.mail.mud.yahoo.com via HTTP; Fri, 14 Apr 2006 01:03:16 PDT Date: Fri, 14 Apr 2006 01:03:16 -0700 (PDT) From: mathew G To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.9 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ipsec] Hi all 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="===============0313119934==" Errors-To: ipsec-bounces@ietf.org --===============0313119934== Content-Type: multipart/alternative; boundary="0-1168739027-1145001796=:26603" Content-Transfer-Encoding: 8bit --0-1168739027-1145001796=:26603 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I am mathew a new member of this mailing mailing list.I have query that how detection of the presence of NAT and NAT-traversal has happened in UMA . If possible please tell me useful links for this. Thanks ad Regards mathew g --------------------------------- How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates. --0-1168739027-1145001796=:26603 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi,
        I am mathew a new member of this mailing mailing list.I have query that how  detection of the presence of NAT and NAT-traversal has happened in UMA .
If possible please tell me useful links for this.
 
Thanks ad Regards
mathew g
 

How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates. --0-1168739027-1145001796=:26603-- --===============0313119934== 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 --===============0313119934==-- From ipsec-bounces@ietf.org Fri Apr 14 04:27:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUJe8-0007QC-2Q; Fri, 14 Apr 2006 04:27:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUJe7-0007Q7-4b for ipsec@ietf.org; Fri, 14 Apr 2006 04:27:15 -0400 Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUJe6-0000g1-7Y for ipsec@ietf.org; Fri, 14 Apr 2006 04:27:15 -0400 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id k3E8R4225999; Fri, 14 Apr 2006 13:57:04 +0530 In-Reply-To: <20060414080316.1170.qmail@web38305.mail.mud.yahoo.com> To: mathew G Subject: Re: [Ipsec] Hi all MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Sripavani.BS@flextronicssoftware.com Date: Fri, 14 Apr 2006 13:56:28 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 04/14/2006 01:56:30 PM, Serialize complete at 04/14/2006 01:56:30 PM X-Spam-Score: 0.2 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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: , Content-Type: multipart/mixed; boundary="===============1869199092==" Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1869199092== Content-Type: multipart/alternative; boundary="=_alternative 002E6B7D65257150_=" This is a multipart message in MIME format. --=_alternative 002E6B7D65257150_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable same with me.. :-) i am Pavani, new to this mailing list. i too have the same query. mathew G =20 04/14/2006 01:33 PM To ipsec@ietf.org cc Subject [Ipsec] Hi all Hi, I am mathew a new member of this mailing mailing list.I have query = that how detection of the presence of NAT and NAT-traversal has happened=20 in UMA . If possible please tell me useful links for this. =20 Thanks ad Regards mathew g =20 How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call=20 rates.=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec *********************** FSS-Unclassified *********************** --=_alternative 002E6B7D65257150_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
same with me.. :-)
i am Pavani, new to this mailing lis= t.
i too have the same query.



mathew G <mathewme= m@yahoo.com>

04/14/2006 01:33 PM

To
ipsec@ietf.org
cc
Subject
[Ipsec] Hi all




Hi,
        I am mathew a new member of this mailing mailing list.I have query that how  detection of the presence of NAT and NAT-traversal has happened in UMA .
If possible please tell me useful links for this.
 
Thanks ad Regards
mathew g
 

How low will we go? Check out Yahoo! Messenger’s l= ow PC-to-Phone call rates.=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



***********************  FSS-Unclassified   *********************= ** --=_alternative 002E6B7D65257150_=-- --===============1869199092== 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 --===============1869199092==-- From ipsec-bounces@ietf.org Fri Apr 14 17:50:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUWBJ-0008Pm-4O; Fri, 14 Apr 2006 17:50:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUWBI-0008Ph-Ip for ipsec@ietf.org; Fri, 14 Apr 2006 17:50:20 -0400 Received: from xproxy.gmail.com ([66.249.82.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUWBG-0001yK-AV for ipsec@ietf.org; Fri, 14 Apr 2006 17:50:20 -0400 Received: by xproxy.gmail.com with SMTP id s12so98187wxc for ; Fri, 14 Apr 2006 14:50:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=e1obt/LRW3JrRnH8Fq3JkynItHCuF6z5gnbem7tiGdHeI9bjZxwjRTP/SRe3SLQ03qd/Un0/qCAtf+6HRxPczNIenFH3waQlo5rjQcZEYjsjYxN5MkwkzELxbIvbXE38I1UGJyUOUFwDzkEjkWfAXLZFQtoiaX61yCz+pxN5lvQ= Received: by 10.70.18.14 with SMTP id 14mr1563343wxr; Fri, 14 Apr 2006 14:50:17 -0700 (PDT) Received: by 10.70.8.7 with HTTP; Fri, 14 Apr 2006 14:50:17 -0700 (PDT) Message-ID: <77ead0ec0604141450o246e99abp2b0582fcb7d6d0bd@mail.gmail.com> Date: Fri, 14 Apr 2006 14:50:17 -0700 From: "Vishwas Manral" To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Ipsec] Applications over IPsec 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="===============1678719932==" Errors-To: ipsec-bounces@ietf.org --===============1678719932== Content-Type: multipart/alternative; boundary="----=_Part_2029_9595561.1145051417916" ------=_Part_2029_9595561.1145051417916 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I had pointed out another issue regarding RFC4305. As we have decided to rehash the RFC I thought we may want to revisit the issue. The link to an earlier discussion is: http://www.atm.tut.fi/list-archive/ipsec-2005/msg00755.html To put the issue more generally, can we have an application which specifies the use of IPsec but states a different set of MUST and SHOULD from RFC4305= . In a sense contradicting the RFC4305. L2TP for example makes Transport mode a MUST though IPsec RFC's state that Tunnel mode is a MUST and and Transpor= t mode is a MAY. Thanks, Vishwas ------=_Part_2029_9595561.1145051417916 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,

I had pointed out another issue regarding RFC4305. As we have decided to rehash the RFC I thought we may want to revisit the issue.

The link to an earlier discussion is:
htt= p://www.atm.tut.fi/list-archive/ipsec-2005/msg00755.html

To put the issue more generally, can we have an application which specifies the use of IPsec but states a different set of MUST and SHOULD from RFC4305. In a sense contradicting the RFC4305. L2TP for example makes Transport mode a MUST though IPsec RFC's state that Tunnel mode is a MUST and and Transport mode is a MAY.

Thanks,
Vishwas

------=_Part_2029_9595561.1145051417916-- --===============1678719932== 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 --===============1678719932==-- From ipsec-bounces@ietf.org Sat Apr 15 10:12:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUlUp-0000D0-Mc; Sat, 15 Apr 2006 10:11:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUlUn-00007w-Ee for ipsec@ietf.org; Sat, 15 Apr 2006 10:11:29 -0400 Received: from web38310.mail.mud.yahoo.com ([209.191.125.26]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FUlUl-0008Vq-PS for ipsec@ietf.org; Sat, 15 Apr 2006 10:11:29 -0400 Received: (qmail 53848 invoked by uid 60001); 15 Apr 2006 14:11:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=47xaCkEG9WvhUUqgLOOIX1ycpx2cIKaiYouodBG2sSQmBvZ48DTJ1xJtKd9LLqNhoIc7ebiEDDAdV+47P7D16RY0yFbfD4Huxjipk078I1+qMg0tpn8nN+anw9kyHcOZg4aERWYpxA9Q4E1HrBmJrlbJNdkx9PLtADMerD/c3JM= ; Message-ID: <20060415141127.53846.qmail@web38310.mail.mud.yahoo.com> Received: from [203.145.155.11] by web38310.mail.mud.yahoo.com via HTTP; Sat, 15 Apr 2006 07:11:27 PDT Date: Sat, 15 Apr 2006 07:11:27 -0700 (PDT) From: mathew G To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ipsec] Hi 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="===============0460178444==" Errors-To: ipsec-bounces@ietf.org --===============0460178444== Content-Type: multipart/alternative; boundary="0-450820854-1145110287=:50802" Content-Transfer-Encoding: 8bit --0-450820854-1145110287=:50802 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Friends, I have doubts , how Ipsequrity mechanisms is implemented between MS and GANC(generic access network controller) for 3gpp networks in IKEV2. Best Regards Mathew G --------------------------------- How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates. --0-450820854-1145110287=:50802 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi Friends,
                 I have doubts , how Ipsequrity mechanisms is implemented between MS and GANC(generic access network controller) for 3gpp networks in IKEV2.
 
Best Regards
Mathew G

How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates. --0-450820854-1145110287=:50802-- --===============0460178444== 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 --===============0460178444==-- From ipsec-bounces@ietf.org Mon Apr 17 11:09:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVVLK-0005FX-LE; Mon, 17 Apr 2006 11:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVVLJ-0005FS-IB for ipsec@ietf.org; Mon, 17 Apr 2006 11:08:45 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVVLH-0002by-1Y for ipsec@ietf.org; Mon, 17 Apr 2006 11:08:45 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FVVLG-0007T1-53; Mon, 17 Apr 2006 11:08:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <77ead0ec0604141450o246e99abp2b0582fcb7d6d0bd@mail.gmail.com> References: <77ead0ec0604141450o246e99abp2b0582fcb7d6d0bd@mail.gmail.com> Date: Mon, 17 Apr 2006 10:52:21 -0400 To: "Vishwas Manral" From: Stephen Kent Subject: Re: [Ipsec] Applications over IPsec X-Spam-Score: 0.5 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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: , Content-Type: multipart/mixed; boundary="===============1293784420==" Errors-To: ipsec-bounces@ietf.org --===============1293784420== Content-Type: multipart/alternative; boundary="============_-1066835975==_ma============" --============_-1066835975==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:50 PM -0700 4/14/06, Vishwas Manral wrote: >Hi, > >I had pointed out another issue regarding RFC4305. As we have >decided to rehash the RFC I thought we may want to revisit the issue. > >The link to an earlier discussion is: >http://www.atm.tut.fi/list-archive/ipsec-2005/msg00755.html > >To put the issue more generally, can we have an application which >specifies the use of IPsec but states a different set of MUST and >SHOULD from RFC4305. In a sense contradicting the RFC4305. L2TP for >example makes Transport mode a MUST though IPsec RFC's state that >Tunnel mode is a MUST and and Transport mode is a MAY. > >Thanks, >Vishwas The only relevant (IPsec) RFC re specification of when to support each of these modes is RFC 4301. It describes when each of these modes MUST be available, depending on the type of device and the way IPsec is used. We modified the text from 2401 to address valid, additional use cases as discussed in the WG, e.g., use of transport mode for overlay nets. It's generally viewed as OK for a protocol using IPsec to require more stringent requirements when it profiles a base standard, but it is not OK to remove requirements. That's the general notion of "profiling" use of one standard in another. In that sense, transforming a MAY into a MUST is just fine. Conversely, transforming a MUST into a MAY is not. Steve --============_-1066835975==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] Applications over IPsec
At 2:50 PM -0700 4/14/06, Vishwas Manral wrote:
Hi,

I had pointed out another issue regarding RFC4305. As we have decided to rehash the RFC I thought we may want to revisit the issue.

The link to an earlier discussion is:
http://www.atm.tut.fi/list-archive/ipsec-2005/msg00755.html

To put the issue more generally, can we have an application which specifies the use of IPsec but states a different set of MUST and SHOULD from RFC4305. In a sense contradicting the RFC4305. L2TP for example makes Transport mode a MUST though IPsec RFC's state that Tunnel mode is a MUST and and Transport mode is a MAY.

Thanks,
Vishwas

The only relevant (IPsec) RFC re specification of when to support each of these modes is RFC 4301. It describes when each of these modes MUST be available, depending on the type of device and the way IPsec is used. We modified the text from 2401 to address valid, additional use cases as discussed in the WG, e.g., use of transport mode for overlay nets.

It's generally viewed as OK for a protocol using IPsec to require more stringent requirements when it profiles a base standard, but it is not OK to remove requirements. That's the general notion of "profiling" use of one standard in another. In that sense, transforming a MAY into a MUST is just fine. Conversely, transforming a MUST into a MAY is not.

Steve
--============_-1066835975==_ma============-- --===============1293784420== 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 --===============1293784420==-- From ipsec-bounces@ietf.org Mon Apr 17 13:54:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXv6-0003j2-DQ; Mon, 17 Apr 2006 13:53:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXv4-0003ir-EX for ipsec@ietf.org; Mon, 17 Apr 2006 13:53:50 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVXv3-00046e-7F for ipsec@ietf.org; Mon, 17 Apr 2006 13:53:50 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FVXv2-0003MH-5s; Mon, 17 Apr 2006 13:53:49 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <77ead0ec0604120955o4e613a5ci176503e3208d916b@mail.gmail.com> References: <77ead0ec0604120955o4e613a5ci176503e3208d916b@mail.gmail.com> Date: Mon, 17 Apr 2006 13:32:27 -0400 To: "Vishwas Manral" From: Stephen Kent Subject: Re: [Ipsec] RFC4305 Errata draft X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: , Content-Type: multipart/mixed; boundary="===============0922924660==" Errors-To: ipsec-bounces@ietf.org --===============0922924660== Content-Type: multipart/alternative; boundary="============_-1066826068==_ma============" --============_-1066826068==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 9:55 AM -0700 4/12/06, Vishwas Manral wrote: >Hi folks, > >I have written a draft >http://www.ietf.org/internet-drafts/draft-manral-ipsec-rfc4305-errata-00.txt >which lists the errata in the RFC4305. > >I think the draft is necessary(instead of just an errata) because >the changes relate mostly chaging a few MUST's to MAY(which is a >much bigger change). as Paul noted, changing a MUST t a MAY makes this a candidate as a replacement RFC, not an errata. Steve --============_-1066826068==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] RFC4305 Errata draft
At 9:55 AM -0700 4/12/06, Vishwas Manral wrote:
Hi folks,

I have written a draft http://www.ietf.org/internet-drafts/draft-manral-ipsec-rfc4305-errata-00.txt which lists the errata in the RFC4305.
I think the draft is necessary(instead of just an errata) because the changes relate mostly chaging a few MUST's to MAY(which is a much bigger change).

as Paul noted, changing a MUST t a MAY makes this a candidate as a replacement RFC, not an errata.

Steve

--============_-1066826068==_ma============-- --===============0922924660== 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 --===============0922924660==-- From ipsec-bounces@ietf.org Mon Apr 17 15:57:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVZql-0001XO-C9; Mon, 17 Apr 2006 15:57:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVZqk-0001X7-Bi for ipsec@ietf.org; Mon, 17 Apr 2006 15:57:30 -0400 Received: from xproxy.gmail.com ([66.249.82.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVZqj-0001XZ-3x for ipsec@ietf.org; Mon, 17 Apr 2006 15:57:30 -0400 Received: by xproxy.gmail.com with SMTP id s12so446683wxc for ; Mon, 17 Apr 2006 12:57:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Krd5Y+8ZyfgyjEWBETpVq3fnMusl4gXwJJvoJ870ulKaaA+STiW+14EtVl1mHBK59cq3BL3ywbx5MEYHk0yFwP/tusH9x4pvUYrgskwQkRXEYKf/9Gd+OLtjUmVV7D1VMp6DDVBZMucX81PhpWlbqu1aWo9ZmG8jQYNWCNaxfsw= Received: by 10.70.35.17 with SMTP id i17mr1118706wxi; Mon, 17 Apr 2006 12:57:28 -0700 (PDT) Received: by 10.70.8.7 with HTTP; Mon, 17 Apr 2006 12:57:28 -0700 (PDT) Message-ID: <77ead0ec0604171257o4c9c4ebfjd6d5d001df7d4c7f@mail.gmail.com> Date: Mon, 17 Apr 2006 12:57:28 -0700 From: "Vishwas Manral" To: "Stephen Kent" Subject: Re: [Ipsec] RFC4305 Errata draft In-Reply-To: MIME-Version: 1.0 References: <77ead0ec0604120955o4e613a5ci176503e3208d916b@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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: , Content-Type: multipart/mixed; boundary="===============1816963960==" Errors-To: ipsec-bounces@ietf.org --===============1816963960== Content-Type: multipart/alternative; boundary="----=_Part_11390_12760624.1145303848794" ------=_Part_11390_12760624.1145303848794 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Steve, I have put in a draft for the replacement rather then an errata. It should be visible sometime soon in the IETF pages. Thanks, Vishwas On 4/17/06, Stephen Kent wrote: > > At 9:55 AM -0700 4/12/06, Vishwas Manral wrote: > > Hi folks, > > I have written a draft > http://www.ietf.org/internet-drafts/draft-manral-ipsec-rfc4305-errat > a-00.txt which lists the errata in the RFC4305. > > I think the draft is necessary(instead of just an errata) because the > changes relate mostly chaging a few MUST's to MAY(which is a much bigger > change). > > > as Paul noted, changing a MUST t a MAY makes this a candidate as a > replacement RFC, not an errata. > > Steve > > ------=_Part_11390_12760624.1145303848794 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Steve,

I have put in a draft for the replacement rather then an errata. It should = be visible sometime soon in the IETF pages.

Thanks,
Vishwas

On 4/17/06, Stephen Kent <kent@bb= n.com> wrote:
At 9:55 AM -0700 4/12/06, Vishwas Manral wrote:
Hi folks,

I have written a draft http://www.ietf.org/internet-drafts/dr= aft-manral-ipsec-rfc4305-errat a-00.txt which lists the errata in the RFC4305.
I think the draft is necessary(instead of just an errata) because the changes relate mostly chaging a few MUST's to MAY(which is a much bigger change).

as Paul noted, changing a MUST t a MAY makes this a candidate as a replacement RFC, not an errata.

Steve


------=_Part_11390_12760624.1145303848794-- --===============1816963960== 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 --===============1816963960==-- From ipsec-bounces@ietf.org Mon Apr 17 21:10:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVeiz-0005ce-NC; Mon, 17 Apr 2006 21:09:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVeiy-0005bX-QA for ipsec@ietf.org; Mon, 17 Apr 2006 21:09:48 -0400 Received: from xproxy.gmail.com ([66.249.82.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVeix-0001kV-Fi for ipsec@ietf.org; Mon, 17 Apr 2006 21:09:48 -0400 Received: by xproxy.gmail.com with SMTP id s12so492700wxc for ; Mon, 17 Apr 2006 18:09:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=S7xXBg38q0Iyl7++pnjvSB+cyABrbw1NM2/OeUHYZWk0sOxZ4d/1a31rmF1szVKtOr/utwt1toT/1BBarCqWFTX+bbkNagb6XtM3+l5imgrPiS71N7ss46bJUVHAjct61VTjM1fAIztMWZia1FZNczvgO6U+amHeNIE/4qQzuhg= Received: by 10.70.87.7 with SMTP id k7mr784345wxb; Mon, 17 Apr 2006 18:09:47 -0700 (PDT) Received: by 10.70.8.7 with HTTP; Mon, 17 Apr 2006 18:09:46 -0700 (PDT) Message-ID: <77ead0ec0604171809v70c534d0h40451d0e4edf59dd@mail.gmail.com> Date: Mon, 17 Apr 2006 18:09:47 -0700 From: "Vishwas Manral" To: "Stephen Kent" Subject: Re: [Ipsec] Applications over IPsec In-Reply-To: MIME-Version: 1.0 References: <77ead0ec0604141450o246e99abp2b0582fcb7d6d0bd@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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: , Content-Type: multipart/mixed; boundary="===============1605948281==" Errors-To: ipsec-bounces@ietf.org --===============1605948281== Content-Type: multipart/alternative; boundary="----=_Part_14838_5364767.1145322587002" ------=_Part_14838_5364767.1145322587002 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Stephen, I see issues in drafts using IPsec then: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txtstate= s that transport mode is a MUST and Tunnel mode is a MAY. This is more related to RFC4301 though. Regarding the algorithms to be supported for ESP and AH(RFC4305), I will ad= d a clear recommendation for applications to use. Thanks, Vishwas On 4/17/06, Stephen Kent wrote: > > At 2:50 PM -0700 4/14/06, Vishwas Manral wrote: > > Hi, > > I had pointed out another issue regarding RFC4305. As we have decided to > rehash the RFC I thought we may want to revisit the issue. > > The link to an earlier discussion is: > http://www.atm.tut.fi/list-archive/ipsec-2005/msg00755.html > > To put the issue more generally, can we have an application which > specifies the use of IPsec but states a different set of MUST and SHOULD > from RFC4305. In a sense contradicting the RFC4305. L2TP for example make= s > Transport mode a MUST though IPsec RFC's state that Tunnel mode is a MUST > and and Transport mode is a MAY. > > Thanks, > > Vishwas > > > The only relevant (IPsec) RFC re specification of when to support each of > these modes is RFC 4301. It describes when each of these modes MUST be > available, depending on the type of device and the way IPsec is used. We > modified the text from 2401 to address valid, additional use cases as > discussed in the WG, e.g., use of transport mode for overlay nets. > > It's generally viewed as OK for a protocol using IPsec to require more > stringent requirements when it profiles a base standard, but it is not OK= to > remove requirements. That's the general notion of "profiling" use of one > standard in another. In that sense, transforming a MAY into a MUST is jus= t > fine. Conversely, transforming a MUST into a MAY is not. > > Steve > ------=_Part_14838_5364767.1145322587002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Stephen,

I see issues in drafts using IPsec then:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.= txt states that transport mode is a MUST and Tunnel mode is a MAY. This is more related to RFC4301 though.

Regarding the algorithms to be supported for ESP and AH(RFC4305), I will ad= d a clear recommendation for applications to use.

Thanks,
Vishwas

On 4/17/06, Stephen Kent <kent@bbn.com&g= t; wrote:
At 2:50 PM -0700 4/14/06, Vishwas Manral wrote:
Hi,

I had pointed out another issue regarding RFC4305. As we have decided to rehash the RFC I thought we may want to revisit the issue.

The link to an earlier discussion is:
htt= p://www.atm.tut.fi/list-archive/ipsec-2005/msg00755.html

To put the issue more generally, can we have an application which specifies the use of IPsec but states a different set of MUST and SHOULD from RFC4305. In a sense contradicting the RFC4305. L2TP for example makes Transport mode a MUST though IPsec RFC's state that Tunnel mode is a MUST and and Transport mode is a MAY.

Thanks,
Vishwas

The only relevant (IPsec) RFC re specification of when to support each of these modes is RFC 4301. It describes when each of these modes MUST be available, depending on the type of device and the way IPsec is used. We modified the text from 2401 to address valid, additional use cases as discussed in the WG, e.g., use of transport mode for overlay nets.

It's generally viewed as OK for a protocol using IPsec to require more stringent requirements when it profiles a base standard, but it is not OK to remove requirements. That's the general notion of "profiling" use of one standard in another. In that sense, transforming a MAY into a MUST is just fine. Conversely, transforming a MUST into a MAY is not.

Steve

------=_Part_14838_5364767.1145322587002-- --===============1605948281== 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 --===============1605948281==-- From ipsec-bounces@ietf.org Tue Apr 18 10:25:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVr8k-0005yX-FF; Tue, 18 Apr 2006 10:25:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVr8h-0005yS-Pr for ipsec@ietf.org; Tue, 18 Apr 2006 10:25:11 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVr8h-0001xp-Gw for ipsec@ietf.org; Tue, 18 Apr 2006 10:25:11 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FVr8h-0002hZ-3K; Tue, 18 Apr 2006 10:25:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <77ead0ec0604171809v70c534d0h40451d0e4edf59dd@mail.gmail.com> References: <77ead0ec0604141450o246e99abp2b0582fcb7d6d0bd@mail.gmail.com> <77ead0ec0604171809v70c534d0h40451d0e4edf59dd@mail.gmail.com> Date: Tue, 18 Apr 2006 09:53:21 -0400 To: "Vishwas Manral" From: Stephen Kent Subject: Re: [Ipsec] Applications over IPsec X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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: , Content-Type: multipart/mixed; boundary="===============2104149841==" Errors-To: ipsec-bounces@ietf.org --===============2104149841== Content-Type: multipart/alternative; boundary="============_-1066752185==_ma============" --============_-1066752185==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 6:09 PM -0700 4/17/06, Vishwas Manral wrote: >Hi Stephen, > >I see issues in drafts using IPsec then: >http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txt >states that transport mode is a MUST and Tunnel mode is a MAY. This >is more related to RFC4301 though. > >Regarding the algorithms to be supported for ESP and AH(RFC4305), I >will add a clear recommendation for applications to use. > >Thanks, >Vishwas yes, I am aware of the OSPFv3 security I-D. The MUST vs. MAY re tunnel and transport modes does not bother me. These folks are defining what an OSPF router has to do as a HOST in the routing environment, not as a GATEWAY. The same would be tyrue if one employed IPsec to protect BGP sessions. The bigger problem is that OSPF needs multicast support and we don't have what they need. The MSEC WG did not provide the necessary extensions to the SPD and SAD to accommodate multicast uses ala OSPF. Thus the OSPF folks tried to make do with what was defined, and the result is not pretty. Steve --============_-1066752185==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] Applications over IPsec
At 6:09 PM -0700 4/17/06, Vishwas Manral wrote:
Hi Stephen,

I see issues in drafts using IPsec then:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txt states that transport mode is a MUST and Tunnel mode is a MAY. This is more related to RFC4301 though.

Regarding the algorithms to be supported for ESP and AH(RFC4305), I will add a clear recommendation for applications to use.

Thanks,
Vishwas


yes, I am aware of the OSPFv3 security I-D.  The MUST vs. MAY re tunnel and transport modes does not bother me.  These folks are defining what an OSPF router has to do as a HOST in the routing environment, not as a GATEWAY. The same would be tyrue if one employed IPsec to protect BGP sessions.

The bigger problem is that OSPF needs multicast support and we don't have what they need.  The MSEC WG did not provide the necessary extensions to the SPD and SAD to accommodate multicast uses ala OSPF. Thus the OSPF folks tried to make do with what was defined, and the result is not pretty.

Steve
--============_-1066752185==_ma============-- --===============2104149841== 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 --===============2104149841==-- From ipsec-bounces@ietf.org Tue Apr 18 13:11:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVtjZ-0005Rc-Qz; Tue, 18 Apr 2006 13:11:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVtjX-0005RX-VN for ipsec@ietf.org; Tue, 18 Apr 2006 13:11:23 -0400 Received: from xproxy.gmail.com ([66.249.82.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVtjX-00021E-Kn for ipsec@ietf.org; Tue, 18 Apr 2006 13:11:23 -0400 Received: by xproxy.gmail.com with SMTP id s12so623074wxc for ; Tue, 18 Apr 2006 10:11:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=NIpqapQ580/toFH6kNJLPnOW40s0ZCKEmuIKSQRWoMGPOlWga9gw9i+tZe9Yv/pp6/qatUkFDfcphpMIVf9i9nJiMwp9gEppa4S8FdDJA9FrAnPHTzOxSvgRtl5N/eBcP8yCe8v7DDE3VQaeHOHtZjWXa6DIDc9y5p2pSAd1e5I= Received: by 10.70.50.17 with SMTP id x17mr1812692wxx; Tue, 18 Apr 2006 10:11:22 -0700 (PDT) Received: by 10.70.8.7 with HTTP; Tue, 18 Apr 2006 10:11:22 -0700 (PDT) Message-ID: <77ead0ec0604181011n5777856cqf3e09ae9d71c83cc@mail.gmail.com> Date: Tue, 18 Apr 2006 10:11:22 -0700 From: "Vishwas Manral" To: "Stephen Kent" Subject: Re: [Ipsec] Applications over IPsec In-Reply-To: MIME-Version: 1.0 References: <77ead0ec0604141450o246e99abp2b0582fcb7d6d0bd@mail.gmail.com> <77ead0ec0604171809v70c534d0h40451d0e4edf59dd@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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: , Content-Type: multipart/mixed; boundary="===============1974616261==" Errors-To: ipsec-bounces@ietf.org --===============1974616261== Content-Type: multipart/alternative; boundary="----=_Part_25338_26617451.1145380282618" ------=_Part_25338_26617451.1145380282618 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Stephen, This is very interesting. I thought because we got a superset of functionality in the tunnel mode(wrt transport mode), we were trying to reduce the number of options we wanted t= o support in IPsec by mandating support for Tunnel mode as a MUST. But if we have applications state that Transport mode is a MUST while a Tunnel mode i= s a MAY, we may have to be supporting both modes. We do not know what applications may run on top right? BTW, the new draft which will obsolete RFC4305 is posted at http://www.ietf.org/internet-drafts/draft-manral-ipsec-rfc4305-bis-errata-0= 0.txt and any comments will be very welcome. Thanks, Vishwas On 4/18/06, Stephen Kent wrote: > > At 6:09 PM -0700 4/17/06, Vishwas Manral wrote: > > Hi Stephen, > > I see issues in drafts using IPsec then: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txtsta= tes that transport mode is a MUST and Tunnel mode is a MAY. This is more > related to RFC4301 though. > > Regarding the algorithms to be supported for ESP and AH(RFC4305), I will > add a clear recommendation for applications to use. > > Thanks, > > Vishwas > > > > yes, I am aware of the OSPFv3 security I-D. The MUST vs. MAY re tunnel > and transport modes does not bother me. These folks are defining what an > OSPF router has to do as a HOST in the routing environment, not as a > GATEWAY. The same would be tyrue if one employed IPsec to protect BGP > sessions. > > The bigger problem is that OSPF needs multicast support and we don't have > what they need. The MSEC WG did not provide the necessary extensions to = the > SPD and SAD to accommodate multicast uses ala OSPF. Thus the OSPF folks > tried to make do with what was defined, and the result is not pretty. > > Steve > ------=_Part_25338_26617451.1145380282618 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Stephen,

This is very interesting.

I thought because we got a superset of functionality in the tunnel mode(wrt transport mode), we were trying to reduce the number of options we wanted to support in IPsec by mandating support for Tunnel mode as a MUST. But if we have applications state that Transport mode is a MUST while a Tunnel mode is a MAY, we may have to be supporting both modes. We do not know what applications may run on top right?
 
BTW, the new draft which will obsolete RFC4305 is posted at
http://www.ietf.org/internet-drafts/draft-manral-ipsec-rf= c4305-bis-errata-00.txt
and any comments will be very welcome.

Thanks,
Vishwas

On 4/18/06, Stephen Kent <kent@bb= n.com> wrote:
At 6:09 PM -0700 4/17/06, Vishwas Manral wrote:
Hi Stephen,

I see issues in drafts using IPsec then:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.= t xt states that transport mode is a MUST and Tunnel mode is a MAY. This is more related to RFC4301 though.

Regarding the algorithms to be supported for ESP and AH(RFC4305), I will add a clear recommendation for applications to use.

Thanks,
Vishwas


yes, I am aware of the OSPFv3 security I-D.  The MUST vs. MAY re tunnel and transport modes does not bother me.  These folks are defining what an OSPF router has to do as a HOST in the routing environment, not as a GATEWAY. The same would be tyrue if one employed IPsec to protect BGP sessions.

The bigger problem is that OSPF needs multicast support and we don't have what they need.  The MSEC WG did not provide the necessary extensions to the SPD and SAD to accommodate multicast uses ala OSPF. Thus the OSPF folks tried to make do with what was defined, and the result is not pretty.

Steve

------=_Part_25338_26617451.1145380282618-- --===============1974616261== 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 --===============1974616261==-- From ipsec-bounces@ietf.org Tue Apr 18 15:51:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVwDs-0005bz-Ch; Tue, 18 Apr 2006 15:50:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVwDq-0005bP-J2 for ipsec@ietf.org; Tue, 18 Apr 2006 15:50:50 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVwDp-0002rb-Cv for ipsec@ietf.org; Tue, 18 Apr 2006 15:50:50 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FVwDp-0006hI-3e; Tue, 18 Apr 2006 15:50:49 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <77ead0ec0604181011n5777856cqf3e09ae9d71c83cc@mail.gmail.com> References: <77ead0ec0604141450o246e99abp2b0582fcb7d6d0bd@mail.gmail.com> <77ead0ec0604171809v70c534d0h40451d0e4edf59dd@mail.gmail.com> <77ead0ec0604181011n5777856cqf3e09ae9d71c83cc@mail.gmail.com> Date: Tue, 18 Apr 2006 15:50:46 -0400 To: "Vishwas Manral" From: Stephen Kent Subject: Re: [Ipsec] Applications over IPsec Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 At 10:11 AM -0700 4/18/06, Vishwas Manral wrote: >Hi Stephen, > >This is very interesting. > >I thought because we got a superset of functionality in the tunnel >mode(wrt transport mode), we were trying to reduce the number of >options we wanted to support in IPsec by mandating support for >Tunnel mode as a MUST. But if we have applications state that >Transport mode is a MUST while a Tunnel mode is a MAY, we may have >to be supporting both modes. We do not know what applications may >run on top right? In the case of OSPv3,. which you cited, the application is very specific and thus the argument you make above does not seem to apply. Mandated support for tunnel vs. transport mode is specific to the implementation context and intended use. Tuunnel mode is not mandated in all contexts. It is mandated for gateways wrt subscriber traffic. A gateway/router MAY use transport mode for management functions in that device, and not support tunnel mode at all if it does not offer IPsec for subscribers. A host MUST support transport mode, but also MAY support tunnel mode. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 18 18:27:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVyfJ-0001t5-HF; Tue, 18 Apr 2006 18:27:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVyfH-0001sX-Cg for ipsec@ietf.org; Tue, 18 Apr 2006 18:27:19 -0400 Received: from smtp-out2.oct.nac.net ([209.123.233.212]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVyfE-0001kP-2y for ipsec@ietf.org; Tue, 18 Apr 2006 18:27:19 -0400 Received: (qmail 5878 invoked from network); 18 Apr 2006 18:27:09 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 18 Apr 2006 18:27:09 -0400 Received: (qmail 42973 invoked from network); 18 Apr 2006 18:27:08 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 18 Apr 2006 18:27:08 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k3IJkHA01904; Tue, 18 Apr 2006 15:46:17 -0400 Date: Tue, 18 Apr 2006 15:46:17 -0400 (EDT) From: George Gross To: Stephen Kent Subject: Re: [Ipsec] Applications over IPsec In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Hi Steve, On Tue, 18 Apr 2006, Stephen Kent wrote: > The bigger problem is that OSPF needs multicast support and we don't > have what they need. The MSEC WG did not provide the necessary > extensions to the SPD and SAD to accommodate multicast uses ala OSPF. > Thus the OSPF folks tried to make do with what was defined, and the > result is not pretty. I was not aware of the OSPF working group's security requirements. AFAICT, no one from the OSPF working group ever posted to MSEC to express those requirements. since MSEC is in the process of composing the MSEC IPsec extensions draft, what exactly are those missing "necessary extensions"? could what OSPF needs from MSEC IPsec be generalized to handle other use cases? tia, George > > Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 19 09:20:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWCbL-0003Ee-8r; Wed, 19 Apr 2006 09:20:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWCbJ-0003ET-V1 for ipsec@ietf.org; Wed, 19 Apr 2006 09:20:09 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWCbI-0003Ae-Od for ipsec@ietf.org; Wed, 19 Apr 2006 09:20:09 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FWCbI-0001dj-4G; Wed, 19 Apr 2006 09:20:08 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 19 Apr 2006 09:17:18 -0400 To: George Gross From: Stephen Kent Subject: Re: [Ipsec] Applications over IPsec Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 At 3:46 PM -0400 4/18/06, George Gross wrote: >Hi Steve, > >On Tue, 18 Apr 2006, Stephen Kent wrote: > > > >> The bigger problem is that OSPF needs multicast support and we don't >> have what they need. The MSEC WG did not provide the necessary >> extensions to the SPD and SAD to accommodate multicast uses ala OSPF. >> Thus the OSPF folks tried to make do with what was defined, and the >> result is not pretty. > >I was not aware of the OSPF working group's security requirements. >AFAICT, no one from the OSPF working group ever posted to MSEC to express >those requirements. since MSEC is in the process of composing the MSEC >IPsec extensions draft, what exactly are those missing "necessary >extensions"? > >could what OSPF needs from MSEC IPsec be generalized to handle other use >cases? > >tia, > George George, Talk with the MSEC WG chairs. The security ADs made them aware of the "missing links" problem several months ago. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 19 11:51:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWExB-0007YF-Kb; Wed, 19 Apr 2006 11:50:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWEx9-0007Y9-Uu for ipsec@ietf.org; Wed, 19 Apr 2006 11:50:51 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWEx7-0001KJ-Hx for ipsec@ietf.org; Wed, 19 Apr 2006 11:50:51 -0400 Received: from [10.20.30.249] (dsl-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 k3JFolxI080392 for ; Wed, 19 Apr 2006 08:50:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 19 Apr 2006 08:50:41 -0700 To: IPsec WG From: The IESG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ipsec] Last Call: 'IKEv2 Clarifications and Implementation Guidelines' to Informational RFC (draft-eronen-ipsec-ikev2-clarifications) 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 IESG has received a request from an individual submitter to consider the following document: - 'IKEv2 Clarifications and Implementation Guidelines' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-05-03. The file can be obtained via http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarifications-08.t xt _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 20 13:17:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWcm0-00031P-98; Thu, 20 Apr 2006 13:16:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWcly-00031K-Tb for ipsec@ietf.org; Thu, 20 Apr 2006 13:16:54 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWcly-0003HB-IW for ipsec@ietf.org; Thu, 20 Apr 2006 13:16:54 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3KHFdeO007102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Apr 2006 10:15:42 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3KHFaMB023010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Apr 2006 10:15:38 -0700 (PDT) Message-Id: <6.2.5.6.2.20060420101153.03f0bca0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 20 Apr 2006 10:15:31 -0700 To: Stephen Kent , "Vishwas Manral" From: Lakshminath Dondeti Subject: Re: [Ipsec] Applications over IPsec In-Reply-To: References: <77ead0ec0604141450o246e99abp2b0582fcb7d6d0bd@mail.gmail.com> <77ead0ec0604171809v70c534d0h40451d0e4edf59dd@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 At 06:53 AM 4/18/2006, Stephen Kent wrote: >At 6:09 PM -0700 4/17/06, Vishwas Manral wrote: >>Hi Stephen, >> >>I see issues in drafts using IPsec then: >>http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txt >>states that transport mode is a MUST and Tunnel mode is a MAY. This >>is more related to RFC4301 though. >> >>Regarding the algorithms to be supported for ESP and AH(RFC4305), I >>will add a clear recommendation for applications to use. >> >>Thanks, >>Vishwas > > >yes, I am aware of the OSPFv3 security I-D. The MUST vs. MAY re >tunnel and transport modes does not bother me. These folks are >defining what an OSPF router has to do as a HOST in the routing >environment, not as a GATEWAY. The same would be tyrue if one >employed IPsec to protect BGP sessions. > >The bigger problem is that OSPF needs multicast support and we don't >have what they need. The MSEC WG did not provide the necessary >extensions to the SPD and SAD to accommodate multicast uses ala >OSPF. Thus the OSPF folks tried to make do with what was defined, >and the result is not pretty. As I read through this thread, I will try and respond to the MSEC work on IPsec extensions. There is in fact work underway on Russ's request to provide extensions to IPsec to support multicast. We've never received requirements from the OSPF group. I recall someone (Sandy perhaps) making a statement at some point that there is interest from the OSPF WG. I will ping the OSPF chairs today to see what's up. thanks and regards, Lakshminath >Steve >_______________________________________________ >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 Thu Apr 20 15:02:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWePn-0003eS-7p; Thu, 20 Apr 2006 15:02:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWePm-0003eN-5A for ipsec@ietf.org; Thu, 20 Apr 2006 15:02:06 -0400 Received: from [216.183.86.37] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWePk-0008Ug-S3 for ipsec@ietf.org; Thu, 20 Apr 2006 15:02:06 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 87082100233FA for ; Thu, 20 Apr 2006 15:02:04 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13889-78 for ; Thu, 20 Apr 2006 15:02:00 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id CA9AE100233C6 for ; Thu, 20 Apr 2006 15:02:00 -0400 (EDT) Received: from [10.0.20.101] ([10.0.20.101]) by certicom1.certicom.com (Lotus Domino Release 6.5.4) with ESMTP id 2006042015020254-40615 ; Thu, 20 Apr 2006 15:02:02 -0400 Message-ID: <4447D7F2.8080604@certicom.com> Date: Thu, 20 Apr 2006 14:50:26 -0400 From: Chinh Nguyen User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org X-Enigmail-Version: 0.92.0.0 X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 04/20/2006 03:02:02 PM, Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 04/20/2006 03:02:03 PM, Serialize complete at 04/20/2006 03:02:03 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Ipsec] RE: Last Call: 'IKE and IKEv2 Authentication Using ECDSA' to Proposed Standard 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 Some comments on last call: 1. "The IANA-assigned attribute number for authentication using generic ECDSA is 8 (see [IANA]), but the parameters and associated hash functions are not specified." If we are going by standards such as X9.62, then hash algorithm is specified. SHA-1 is the hash algorithm for ECDSA (X9.62 section 5.3.1). As to the EC parameters, you can argue (or clarify) that it can be retrieved from your public/private EC key. As such, the current chart for IKEv1 could look like this: Digital Diffie- IANA Signature Hellman Hash Value Algorithm Group Function ----- --------- ------------ ------------- 8 ECDSA any SHA-1 9 ECDSA P-256 [19] SHA-256 [4] 10 ECDSA P-384 [20] SHA-384 [5] 11 ECDSA P-512 [21] SHA-512 [6] 2. "the signature payload SHALL contain an encoding of the computed signature consisting of the concatenation of a pair of integers s and t." Pasi Eronen has suggested DER-encoding of ECDSA-Sig-Value. It is interesting to note that this was the language in earlier drafts (e.g. draft-ietf-ipsec-ike-auth-ecdsa-02.txt) The downside is (DER) ASN.1 parsing hairiness although it's true that you don't need a full-blown ASN.1 parser. You can simplify by looking for the byte sequence that would represent ECDSA-Sig-Value. Concatenation of "r" and "s" (R|S), in the integer-to-octet-string sense, is certainly simpler. However, it must be clarified that the size of r of s in bytes must be the same as q, the group order. For example, some 160-bit curve has 161-bit q and therefore r and s are actually 21 bytes long and not 20 bytes. The easiest way to state this would be to specify that r and s must be the same length and therefore r and/or s must be 0-padded if necessary. 3. "If the signature (s,t) were the one appearing in the authentication payload, then the payload would be as follows. 00000048 00090000 CB28E099 9B9C7715 FD0A80D8 E47A7707 9716CBBF 917DD72E 97566EA1 C066957C 86FA3BB4 E26CAD5B F90B7F81 899256CE 7594BB1E A0C89212 748BFF3B 3D5B0315" All test vectors in section 6 have this format. There are 2 issues: First, this looks an IKEv2 Authentication Payload? The Signature Payload in IKEv1 would not have the authentication method and reserved field as above (i.e., "00090000"). This should be clarified or both types of payload should appear in section 6. If this is in fact an IKEv1 signature payload, then the signature would seem to be (auth method in 16-bit hex|0x0000|r|s)? Second, if it is an IKEv2 Auth Payload, the auth method field occupies only 1 octet. So the above example should be "09000000". Regards, Chinh -- http://www.certicom.com/ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 20 15:24:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWelJ-00043x-MR; Thu, 20 Apr 2006 15:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWelH-00043s-NS for ipsec@ietf.org; Thu, 20 Apr 2006 15:24:19 -0400 Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWelH-0001EV-Bq for ipsec@ietf.org; Thu, 20 Apr 2006 15:24:19 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IY1003W3CKEXW00@dps.sfvic.sunlabs.com> for ipsec@ietf.org; Thu, 20 Apr 2006 12:24:14 -0700 (PDT) Received: from [152.70.69.223] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IY100J9MCK6P9F1@mail.sunlabs.com> for ipsec@ietf.org; Thu, 20 Apr 2006 12:24:14 -0700 (PDT) Date: Thu, 20 Apr 2006 12:24:07 -0700 From: Vipul Gupta Subject: Re: [Ipsec] RE: Last Call: 'IKE and IKEv2 Authentication Using ECDSA' to Proposed Standard In-reply-to: <4447D7F2.8080604@certicom.com> To: Chinh Nguyen Message-id: <549FC185-F54D-4DE4-9DA6-5A6DF81661A3@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.749.3) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <4447D7F2.8080604@certicom.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Apr 20, 2006, at 11:50 AM, Chinh Nguyen wrote: > Some comments on last call: > > 2. "the signature payload SHALL contain an encoding of the computed > signature > consisting of the concatenation of a pair of integers s and t." > > Pasi Eronen has suggested DER-encoding of ECDSA-Sig-Value. It is > interesting to > note that this was the language in earlier drafts (e.g. > draft-ietf-ipsec-ike-auth-ecdsa-02.txt) In the TLS working group, we recently went through a similar discussion for the "ECC Cipher Suites in TLS" draft. The wording in the draft suggested *not* using DER encoding but it turned out that most implementers felt that DER encoding was easier to accommodate since they already needed code to generate/parse DER encoded signatures to deal with ECC certificates. In the end, we sought and received permission from the WG chairs and the Security ADs to change the wording in the draft to do DER encoding. This also makes things consistent with plain DSA and is being implemented in the ECC/TLS implementations from Certicom, OpenSSL, Microsoft, Red Hat and Sun. See: http://www1.ietf.org/mail-archive/web/tls/current/msg00555.html http://dev.experimentalstuff.com:8082/ Just something to consider. vipul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 26 03:11:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYeAo-0000Xe-6u; Wed, 26 Apr 2006 03:10:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYeAm-0000XZ-Uq for ipsec@ietf.org; Wed, 26 Apr 2006 03:10:52 -0400 Received: from partner03.net.globalnet.hr ([213.149.47.228] helo=mail.dmz.partner-banka.hr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYeAl-0000Np-1e for ipsec@ietf.org; Wed, 26 Apr 2006 03:10:52 -0400 Received: from mail.dmz.partner-banka.hr (localhost.localdomain [127.0.0.1]) by localhost.dmz.partner-banka.hr (Postfix) with ESMTP id 1DF2D8964 for ; Wed, 26 Apr 2006 09:10:44 +0200 (CEST) Received: from fedora.centrala.partner-banka.hr (unknown [197.100.1.8])by mail.dmz.partner-banka.hr (Postfix) with ESMTP id F4095892Cfor ; Wed, 26 Apr 2006 09:10:43 +0200 (CEST) From: Stjepan Gros To: ipsec@ietf.org Content-Type: text/plain Date: Wed, 26 Apr 2006 09:10:30 +0200 Message-Id: <1146035430.2698.3.camel@estella.zemris.fer.hr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-imss-version: 2.038 X-imss-result: Passed X-imss-scores: Clean:32.83020 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: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Ipsec] Next IKEv2 interoperability testing... 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 Hi all, I'm just wandering, are there any plans for the next IKEv2 interoprability workshop? Thanks in advance, Stjepan Gros _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 26 18:38:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYseW-0003ZV-QR; Wed, 26 Apr 2006 18:38:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYseV-0003ZO-Gp for ipsec@ietf.org; Wed, 26 Apr 2006 18:38:31 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYseV-00040B-4l for ipsec@ietf.org; Wed, 26 Apr 2006 18:38:31 -0400 Received: from [165.227.249.220] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3QMcRjT000524 for ; Wed, 26 Apr 2006 15:38:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 26 Apr 2006 15:38:22 -0700 To: IPsec WG From: rfc-editor@rfc-editor.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Ipsec] RFC 4478 on Repeated Authentication in Internet Key Exchange (IKEv2) Protocol 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 Request for Comments is now available in online RFC libraries. RFC 4478 Title: Repeated Authentication in Internet Key Exchange (IKEv2) Protocol Author: Y. Nir Status: Experimental Date: April 2006 Mailbox: ynir@checkpoint.com Pages: 5 Characters: 10714 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-nir-ikev2-auth-lt-05.txt URL: http://www.rfc-editor.org/rfc/rfc4478.txt This document extends the Internet Key Exchange (IKEv2) Protocol document [IKEv2]. With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer. This document describes a mechanism to perform this function. This memo defines an Experimental Protocol for the Internet community. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Apr 30 07:00:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fa9eP-0003g1-4n; Sun, 30 Apr 2006 06:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fa9eO-0003fw-I4 for ipsec@ietf.org; Sun, 30 Apr 2006 06:59:40 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fa9eN-0005F8-0E for ipsec@ietf.org; Sun, 30 Apr 2006 06:59:40 -0400 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 k3UAxN4Q025202; Sun, 30 Apr 2006 13:59:24 +0300 (IDT) Message-ID: <4454988C.8030205@checkpoint.com> Date: Sun, 30 Apr 2006 13:59:24 +0300 From: Yoav Nir Organization: Check Point User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: pasi.eronen@nokia.com, ipsec@ietf.org Subject: [Fwd: [Ipsec] Last Call: 'IKEv2 Clarifications and Implementation Guidelines' to Informational RFC (draft-eronen-ipsec-ikev2-clarifications)] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Hi. Section 5.2 (bottom of page 24) mentions ongoing work to add the re-authentication feature. This has now been published, so you should probably fix the wording as well as the [ReAuth] reference. It is now RFC 4478. -------- Original Message -------- Subject: [Ipsec] Last Call: 'IKEv2 Clarifications and Implementation Guidelines' to Informational RFC (draft-eronen-ipsec-ikev2-clarifications) Date: Wed, 19 Apr 2006 08:50:41 -0700 From: The IESG To: IPsec WG The IESG has received a request from an individual submitter to consider the following document: - 'IKEv2 Clarifications and Implementation Guidelines' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-05-03. The file can be obtained via http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarifications-08.t xt _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ 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 Sun Apr 30 11:58:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaEIQ-0003kr-3p; Sun, 30 Apr 2006 11:57:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaEIO-0003iH-K0 for ipsec@ietf.org; Sun, 30 Apr 2006 11:57:16 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaEIO-0000z0-8a for ipsec@ietf.org; Sun, 30 Apr 2006 11:57:16 -0400 Received: from [10.20.30.249] (dsl-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 k3UFv3k6049627; Sun, 30 Apr 2006 08:57:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4454988C.8030205@checkpoint.com> References: <4454988C.8030205@checkpoint.com> Date: Sun, 30 Apr 2006 08:57:01 -0700 To: Yoav Nir , pasi.eronen@nokia.com, ipsec@ietf.org From: Paul Hoffman Subject: Re: [Fwd: [Ipsec] Last Call: 'IKEv2 Clarifications and Implementation Guidelines' to Informational RFC (draft-eronen-ipsec-ikev2-clarifications)] Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.6 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 At 1:59 PM +0300 4/30/06, Yoav Nir wrote: >Section 5.2 (bottom of page 24) mentions ongoing work to add the >re-authentication feature. > >This has now been published, so you should probably fix the wording >as well as the [ReAuth] reference. It is now RFC 4478. Already caught that, thanks! We're still hoping to hear more from IKEv2 implementers on the draft, of course. The IETF last call closes in a few days. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec