From Internet-Drafts@ietf.org Fri Apr 1 05:45:04 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B84C3A6835; Fri, 1 Apr 2011 05:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkQ4pE6WKL9b; Fri, 1 Apr 2011 05:45:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 288EE3A683A; Fri, 1 Apr 2011 05:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110401124502.9508.38954.idtracker@localhost> Date: Fri, 01 Apr 2011 05:45:02 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 12:45:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : A Quick Crash Detection Method for IKE Author(s) : Y. Nir, et al. Filename : draft-ietf-ipsecme-failure-detection-08.txt Pages : 24 Date : 2011-04-01 This document describes an extension to the IKEv2 protocol that allows for faster detection of Security Association (SA) desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text we propose an extension to the protocol, that allows for recovery immediately following the restart. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-detection-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-failure-detection-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-01053336.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Fri Apr 1 06:33:14 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FA923A684E; Fri, 1 Apr 2011 06:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ-w2tnvISBx; Fri, 1 Apr 2011 06:33:13 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871043A686A; Fri, 1 Apr 2011 06:33:13 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110401133313.21603.10776.idtracker@localhost> Date: Fri, 01 Apr 2011 06:33:13 -0700 Cc: ipsecme mailing list , ipsecme chair , RFC Editor Subject: [IPsec] Protocol Action: 'A Quick Crash Detection Method for IKE' to Proposed Standard (draft-ietf-ipsecme-failure-detection-08.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 13:33:14 -0000 The IESG has approved the following document: - 'A Quick Crash Detection Method for IKE' (draft-ietf-ipsecme-failure-detection-08.txt) as a Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Sean Turner and Tim Polk. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipsecme-failure-detection/ Technical Summary When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred. This delays the recovery of the tunnel. This document describes an IKEv2 extension that allows discovery of the reboot almost immediately after the rebooted system is active again. Working Group Summary There was consensus both that this is a problem that needs to be solved and for the proposed solution. Document Quality Some vendors expressed interest in implementing this in their IPsec gateways. Personnel Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd. Sean Turner (turners@ieca.com) is the responsible AD. Tero Kivinen (kivinen@iki.fi) is the expert reviewer. From turners@ieca.com Sat Apr 2 08:04:44 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FC573A683D for ; Sat, 2 Apr 2011 08:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwyNsslpVHCx for ; Sat, 2 Apr 2011 08:04:43 -0700 (PDT) Received: from nm1-vm0.bullet.mail.sp2.yahoo.com (nm1-vm0.bullet.mail.sp2.yahoo.com [98.139.91.202]) by core3.amsl.com (Postfix) with SMTP id 713C33A683C for ; Sat, 2 Apr 2011 08:04:43 -0700 (PDT) Received: from [98.139.91.65] by nm1.bullet.mail.sp2.yahoo.com with NNFMP; 02 Apr 2011 15:06:19 -0000 Received: from [98.139.91.48] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 02 Apr 2011 15:06:19 -0000 Received: from [127.0.0.1] by omp1048.mail.sp2.yahoo.com with NNFMP; 02 Apr 2011 15:06:19 -0000 X-Yahoo-Newman-Id: 56988.56594.bm@omp1048.mail.sp2.yahoo.com Received: (qmail 52420 invoked from network); 2 Apr 2011 15:06:19 -0000 Received: from thunderfish.local (turners@198.180.150.234 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 02 Apr 2011 08:06:18 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: kjIb0uAVM1kjf8euKSmh4.hIWGzLptO5PBr0051ELmRhdwc 7Sl7ew2BEHt3fm26bDpTESf5eJM9uA_EZQ5MsaYFgk6OP.xPnO1LRfspow1A D300RRqAz9Q9eT_e2u.ItZ.AyCRyRDQjlxdmLQhtsyjfLl8GMWtNk_aaDo77 L725yu2uXC6BS4ic9owP2rWqlgDqoClW4EIeiJQpJYJs.qE7KkywK9pKFSEI .VrUjZYPym4PLjcarXpz2zx16QET6gMAqJC.D86vsGWMn6b7iND.Gh38vh3G L8GnJYF.pJpLK9UBFHZ4vBskSK7bU0URZDT4okZOPdJtRAsZLo1kpZsdPnhi JwZFCXO68vQ4A5Yr7ilFlWqAI3KbpW7V8SzFApmi. X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D973B68.1060502@ieca.com> Date: Sat, 02 Apr 2011 17:06:16 +0200 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: multipart/mixed; boundary="------------070909030701090609040709" Subject: [IPsec] Fwd: I-D Action:draft-yeung-g-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 15:04:44 -0000 This is a multi-part message in MIME format. --------------070909030701090609040709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This might interest some on this mailing list. spt -------- Original Message -------- Subject: I-D Action:draft-yeung-g-ikev2-02.txt Date: Mon, 14 Mar 2011 15:30:08 -0700 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Group Key Management using IKEv2 Author(s) : S. Rowles, et al. Filename : draft-yeung-g-ikev2-02.txt Pages : 45 Date : 2011-03-14 This document presents a new group key distribution protocol, using group key distribution RFC 3547 with IKEv2 RFC 5996. The new protocol is similar to IKEv2 in message and payload formats as well as message semantics. The protocol is in conformance with MSEC key management architecture that it contains two components: member registration and group rekeying, both downloading group security associations from the Group Controller Key Server to a member of the group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yeung-g-ikev2-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------070909030701090609040709 Content-Type: Message/External-body; name="draft-yeung-g-ikev2-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-yeung-g-ikev2-02.txt" Content-Type: text/plain Content-ID: <2011-03-14152551.I-D@ietf.org> --------------070909030701090609040709 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------070909030701090609040709-- From VSasi@ixiacom.com Tue Apr 5 07:16:16 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11D7B28C11D for ; Tue, 5 Apr 2011 07:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ChkuUHj5Ta5 for ; Tue, 5 Apr 2011 07:16:15 -0700 (PDT) Received: from ixqw-mail-out.ixiacom.com (ixqw-mail-out.ixiacom.com [66.77.12.12]) by core3.amsl.com (Postfix) with ESMTP id 90D9628C115 for ; Tue, 5 Apr 2011 07:16:15 -0700 (PDT) Received: from ixcaexch07.ixiacom.com ([fe80:0000:0000:0000:e021:fcf5:238.143.231.20]) by ixqw-hc1.ixiacom.com ([10.210.5.15]) with mapi; Tue, 5 Apr 2011 07:17:58 -0700 From: Vinod Sasi To: "'ipsec@ietf.org'" Date: Tue, 5 Apr 2011 07:17:58 -0700 Thread-Topic: Queries relating to ESP/AH GCM & GMAC Thread-Index: AcvznEI7HgmLeLnIR0OYbicIGlj+mg== Message-ID: <716209EC190CA740BA799AC4ACCBFB5D1851CEE709@IXCAEXCH07.ixiacom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_716209EC190CA740BA799AC4ACCBFB5D1851CEE709IXCAEXCH07ixi_" MIME-Version: 1.0 Subject: [IPsec] Queries relating to ESP/AH GCM & GMAC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 14:16:16 -0000 --_000_716209EC190CA740BA799AC4ACCBFB5D1851CEE709IXCAEXCH07ixi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been reading RFC 4106 & 4543 over the past 2 weeks & in the process = of implementing this RFC for IKEv1 module for my customer. There is a long pending clarification, Appreciate your help on establishing= clarity. 1. What is the scope of Authentication between ESP GMAC & AH GMAC? Shall = I use the understanding outlined in RFC 2401 Section 4.2 Pg 9? 2. What is the IV mode for GCM & GMAC? How to establish IV synchronizatio= n between the sender & receiver. For (e.g.) AES the IV is placed as the fir= st 16-byte block before Cipher text & sent over the wire. Do I follow the s= ame for GCM/GMAC? Thanks in advance, Vinod --_000_716209EC190CA740BA799AC4ACCBFB5D1851CEE709IXCAEXCH07ixi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have been reading RFC 4106 & 454= 3 over the past 2 weeks & in the process of implementing this RFC for IKE= v1 module for my customer.

 

There is a long pending clarification, Appreciate your help on establishing clarity.

 

  1. What is the scope of Authentication between ESP GMAC & AH GMAC? Shall I use the understanding outlined in RFC 2401 Section 4.2 Pg 9?
  2. What is the IV mode for G= CM & GMAC? How to establish IV synchronization between the sender &am= p; receiver. For (e.g.) AES the IV is placed as the first 16-byte block before Cipher text & sent over the wire. Do I follow the same for GCM/GMAC?

 

Thanks in advance,

Vinod

 

--_000_716209EC190CA740BA799AC4ACCBFB5D1851CEE709IXCAEXCH07ixi_-- From sfluhrer@cisco.com Tue Apr 5 08:58:48 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB083A6955 for ; Tue, 5 Apr 2011 08:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djOHxAMRBAbF for ; Tue, 5 Apr 2011 08:58:41 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7BB4C3A694C for ; Tue, 5 Apr 2011 08:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sfluhrer@cisco.com; l=18324; q=dns/txt; s=iport; t=1302019225; x=1303228825; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=HQBeBF2KRbdzRsb5Wq6JinzoGnvScU/Mm1VX7Lv9lq0=; b=aFOM4LxQxcFxY1P/jz1UrIlXaQ37mqWompVzeL10CDSB29VfdO517ce7 HL5IjE0LW9/kcQDxp1KEFmxS0shsYAp+HvLvwmQevFhRjJPkXnXPW506/ 2v4YbsUwi5VqkPeqEhfrAO72w6in6AYRepy77aW/xbdGssH89+S7bJTcV c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAOg7m02rRDoJ/2dsb2JhbACCYJVBjUh3px+cJIVsBIVHiz8 X-IronPort-AV: E=Sophos;i="4.63,305,1299456000"; d="scan'208,217";a="331053180" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 05 Apr 2011 16:00:24 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p35G0N2W028620; Tue, 5 Apr 2011 16:00:24 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Apr 2011 09:00:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF3AA.8CC716AC" Date: Tue, 5 Apr 2011 09:00:11 -0700 Message-ID: In-Reply-To: <716209EC190CA740BA799AC4ACCBFB5D1851CEE709@IXCAEXCH07.ixiacom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Queries relating to ESP/AH GCM & GMAC Thread-Index: AcvznEI7HgmLeLnIR0OYbicIGlj+mgAB5wdg X-Priority: 5 Priority: Non-Urgent Importance: low References: <716209EC190CA740BA799AC4ACCBFB5D1851CEE709@IXCAEXCH07.ixiacom.com> From: "Scott Fluhrer (sfluhrer)" To: "Vinod Sasi" , X-OriginalArrivalTime: 05 Apr 2011 16:00:14.0439 (UTC) FILETIME=[8CEAF770:01CBF3AA] Subject: Re: [IPsec] Queries relating to ESP/AH GCM & GMAC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 15:58:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF3AA.8CC716AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Vinod Sasi Sent: Tuesday, April 05, 2011 10:18 AM To: 'ipsec@ietf.org' Subject: [IPsec] Queries relating to ESP/AH GCM & GMAC =20 Hello, =20 I have been reading RFC 4106 & 4543 over the past 2 weeks & in the process of implementing this RFC for IKEv1 module for my customer.=20 =20 There is a long pending clarification, Appreciate your help on establishing clarity. =20 1. What is the scope of Authentication between ESP GMAC & AH GMAC? Shall I use the understanding outlined in RFC 2401 Section 4.2 Pg 9? I'd use the more detailed descriptions in RFC 4303 and 4302; they define exactly what fields are included in the integrity check and (for AH) which fields are considered 'mutable' (and are implicitly replaced by zeros for the purposes of doing the integrity check). =20 =20 2. What is the IV mode for GCM & GMAC? How to establish IV synchronization between the sender & receiver. For (e.g.) AES the IV is placed as the first 16-byte block before Cipher text & sent over the wire. Do I follow the same for GCM/GMAC? It's explained in RFC 4106; the encryptor picks an 8 byte IV, and includes it in the packet; the decryptor extracts this 8 byte IV from the packet. Note that the GCM/GMAC nonce is actually 12 bytes; 8 bytes come from the IV, and the other 4 bytes come from the keying material ("salt"). =20 Also, important note (RFC 4106 mentions it; it's important enough for me to reiterate it); it's critical that you never generate two packets with the same IV (for the same GCM/GMAC key). GCM IVs are not the same as CBC-mode IVs. With CBC mode, what's important is that the IV be unpredictable (and so, say, using a random number generator to pick CBC-mode IVs is a good solution). With GCM, it doesn't matter in the slightest if the IV is unpredictable; what's important is that they never repeat. Randomly picking GCM mode IVs will mean that you'll likely to get a repeat after a few billion packets; that'd be bad. Instead, one good way of picking the IVs is to use a counter (you could even reuse the IPSec sequence number if your implementation makes that convenient). =20 =20 Some other subtle points: - ESP GMAC is technically a 'combined mode'; what this means is that, as far as IPSec is concerned, it's both an encryption algorithm and an authentication algorithm. It doesn't actually provide confidentiality, but it is considered an encryption algorithm in the same way that ESP NULL is. One implication of that is that it can't be used with, say, ESP AES CBC (just like you can't use both ESP AES CBC and ESP NULL in the same SA). If you want both confidentially and integrity, use either ESP-GCM, or AH GMAC and your favorite ESP encryption algorithm. - AH GMAC and IPv6 has a glitch which I don't think are mentioned explicitly in the RFCs; AH is an 'extension header' within IPv6, and the IPv6 RFC (2460, see section 4) must be a multiple of 8 octets in length. However, a straight-forward implementation of the AH header with RFC 4543 would yield a 28 octet header (12 octets for the next header/payload length/SPI/seqno, and 16 octets for the ICV value); 28 is not a multiple of 8. What you need to do (if you're serious about following the IPv6 RFC) is include an additional 4 octets after the ICV if you're using IPv6. I'd make those 4 octets all zeros; that way, you don't have to worry whether the other side considers them mutable or not. =20 =20 Thanks in advance, Vinod =20 ------_=_NextPart_001_01CBF3AA.8CC716AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Vinod Sasi
Sent: Tuesday, April 05, 2011 10:18 AM
To: 'ipsec@ietf.org'
Subject: [IPsec] Queries relating to ESP/AH GCM & = GMAC

 

Hello,

 

I have been reading RFC 4106 & 4543 over the past 2 = weeks & in the process of implementing this RFC for IKEv1 module for my = customer.

 

There is a long pending clarification, Appreciate your help = on establishing clarity.

 

  1. What is = the scope of Authentication between ESP GMAC & AH GMAC? Shall I use = the understanding outlined in RFC 2401 Section 4.2 Pg = 9?

I’d use the more detailed descriptions in RFC 4303 = and 4302; they define exactly what fields are included in the integrity check and = (for AH) which fields are considered ‘mutable’ (and are = implicitly replaced by zeros for the purposes of doing the integrity = check).

 

 

  1. What is = the IV mode for GCM & GMAC? How to establish IV synchronization = between the sender & receiver. For (e.g.) AES the IV is placed as the first 16-byte block before Cipher text & sent over the wire. Do I = follow the same for GCM/GMAC?

It’s explained in RFC 4106; the encryptor picks an 8 = byte IV, and includes it in the packet; the decryptor extracts this 8 byte IV = from the packet.  Note that the GCM/GMAC nonce is actually 12 bytes; 8 = bytes come from the IV, and the other 4 bytes come from the keying material = (“salt”).

 

Also, important note (RFC 4106 mentions it; it’s = important enough for me to reiterate it); it’s critical that you never generate two packets with the same IV (for the same GCM/GMAC key).  GCM IVs are = not the same as CBC-mode IVs.  With CBC mode, what’s important is = that the IV be unpredictable (and so, say, using a random number generator to = pick CBC-mode IVs is a good solution).  With GCM, it doesn’t = matter in the slightest if the IV is unpredictable; what’s important is that = they never repeat.  Randomly picking GCM mode IVs will mean that = you’ll likely to get a repeat after a few billion packets; that’d be bad. Instead, one good way of picking the IVs is to use a counter (you could = even reuse the IPSec sequence number if your implementation makes that = convenient).

 

 

Some other subtle points:

-          ESP GMAC is technically a ‘combined mode’; what = this means is that, as far as IPSec is concerned, it’s both an = encryption algorithm and an authentication algorithm.  It doesn’t = actually provide confidentiality, but it is considered an encryption algorithm in = the same way that ESP NULL is.  One implication of that is that it = can’t be used with, say, ESP AES CBC (just like you can’t use both ESP = AES CBC and ESP NULL in the same SA).  If you want both confidentially and = integrity, use either ESP-GCM, or AH GMAC and your favorite ESP encryption = algorithm.

-          AH GMAC and IPv6 has a glitch which I don’t think are mentioned explicitly in the RFCs; AH is an ‘extension = header’ within IPv6, and the IPv6 RFC (2460, see section 4) must be a multiple = of 8 octets in length.  However, a straight-forward implementation of = the AH header with RFC 4543 would yield a 28 octet header (12 octets for the = next header/payload length/SPI/seqno, and 16 octets for the ICV value); 28 is = not a multiple of 8.  What you need to do (if you’re serious about following the IPv6 RFC) is include an additional 4 octets after the ICV = if you’re using IPv6.  I’d make those 4 octets all zeros; that way, you = don’t have to worry whether the other side considers them mutable or = not.

 

 

Thanks in advance,

Vinod

 

------_=_NextPart_001_01CBF3AA.8CC716AC-- From frank.bailey@securecommconsulting.com Tue Apr 5 14:05:56 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34ED53A67D4 for ; Tue, 5 Apr 2011 14:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.336 X-Spam-Level: X-Spam-Status: No, score=-0.336 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZpUBEyBPfhh for ; Tue, 5 Apr 2011 14:05:52 -0700 (PDT) Received: from remote.securecommaz.com (wsip-174-79-50-29.ph.ph.cox.net [174.79.50.29]) by core3.amsl.com (Postfix) with ESMTP id BECFE3A67C0 for ; Tue, 5 Apr 2011 14:05:52 -0700 (PDT) Received: from DCMS.securecomm.local ([fe80::b454:c9af:6881:298c]) by DCMS.securecomm.local ([fe80::b454:c9af:6881:298c%10]) with mapi; Tue, 5 Apr 2011 14:07:32 -0700 From: Frank Bailey To: "ipsec@ietf.org" Date: Tue, 5 Apr 2011 14:07:30 -0700 Thread-Topic: RFC 5996: IKEv2 - rekey question about 'equivalent' SA's Thread-Index: Acvz1XnhQaPrCeHYQcihq3h1AtX1GA== Message-ID: <2D3A22855517F24E9B960D4D353AABC90A293199E8@DCMS.securecomm.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2D3A22855517F24E9B960D4D353AABC90A293199E8DCMSsecurecom_" MIME-Version: 1.0 Subject: [IPsec] RFC 5996: IKEv2 - rekey question about 'equivalent' SA's X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 22:43:29 -0000 --_000_2D3A22855517F24E9B960D4D353AABC90A293199E8DCMSsecurecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a question about what is meant by 'equivalent' SA's wrt to rekeying. If someone has already addressed this, my apologies and please point to the thread I missed. - thx. In section 2.8 it talks about when rekeying a Child SA or an IKE SA, that the peers should establish an 'equivalent' SA. The question I have, is what is meant by equivalent? Does that mean there can only be one proposal in the SA when rekeying? And, does that proposal have to match the currently used algorithms for that SA (i.e. the new SA, must match the SA (as far as transforms) to be rekeyed)? In section 2.18, 4th paragraph, it mentions that the 'old and new IKE SA may have selected a different PRF. ...' Which leads me to think that we can re-negotiate the transforms during a rekey. - thanks in advance for the help, Frank B. --_000_2D3A22855517F24E9B960D4D353AABC90A293199E8DCMSsecurecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have a questio= n about what is meant by ‘equivalent’ SA’s wrt=

to rekeying.   If someone has already ad= dressed this, my apologies

and please po= int to the thread I missed. – thx.

 

In section 2.8 it talks about wh= en rekeying a Child SA or an IKE SA, that

the peers should establish an ‘equivalent’ SA.  The ques= tion I have,

is what is meant by equival= ent?  Does that mean there can only be

one proposal in the SA when rekeying? And, does that proposal have=

to match the currently used algorithms for t= hat SA (i.e. the new SA,

must match the = SA (as far as transforms) to be rekeyed)?

 

In section 2.18, 4th= paragraph, it mentions that the ‘old and new IKE SA

may have selected a different PRF. …’ &= nbsp;  Which leads me to think that

we can re-negotiate the transforms during a rekey.

 

-  = ;        thanks = in advance for the help, Frank B.

&= nbsp;

 

= --_000_2D3A22855517F24E9B960D4D353AABC90A293199E8DCMSsecurecom_-- From nico@cryptonector.com Tue Apr 5 16:21:30 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30363A699F for ; Tue, 5 Apr 2011 16:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjeHnnWzETDK for ; Tue, 5 Apr 2011 16:21:30 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id 2F1603A698D for ; Tue, 5 Apr 2011 16:21:30 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 8D5F31B406B for ; Tue, 5 Apr 2011 16:23:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=ovHVDaNqeN63gqXfh52yKvByjfzO0f5ArHE3yl9dubta NN4Vu3HUdBan+sbuIyP1YdpeB2fu1rvNyYBtQKprJ5YqVsQlPbqVFSDyaXC9LSpq poBeHRjWYanmxTZpkstMtiPrVkIwEXiuxgIcYS4mOK22dzFqqK4AkD+wX7Z2plE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=N69RwUako47YvHqf3tZ83zq+D78=; b=c0n7+sOdhxt eI5RsPAflv0i9EYJRgNrrkqhwSRz4Rgrj4PKe/yySTrDrXW4Ar1gDXRx6M/NH2xF K/+8oaCuabCFCLBZBRYb1EbSWt8dfsdERfGfgXvNz/uj8qJF8KX2ojwDl4YPxk8r Htci0dM4KoTCfVXYG1HHBFMHj1Mipqug= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 24ED61B405F for ; Tue, 5 Apr 2011 16:23:13 -0700 (PDT) Received: by vws12 with SMTP id 12so876088vws.31 for ; Tue, 05 Apr 2011 16:23:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.74.106 with SMTP id s10mr387788vdv.150.1302045792433; Tue, 05 Apr 2011 16:23:12 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Tue, 5 Apr 2011 16:23:12 -0700 (PDT) In-Reply-To: <2D3A22855517F24E9B960D4D353AABC90A293199E8@DCMS.securecomm.local> References: <2D3A22855517F24E9B960D4D353AABC90A293199E8@DCMS.securecomm.local> Date: Tue, 5 Apr 2011 18:23:12 -0500 Message-ID: From: Nico Williams To: Frank Bailey Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" Subject: Re: [IPsec] RFC 5996: IKEv2 - rekey question about 'equivalent' SA's X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 23:21:31 -0000 On Tue, Apr 5, 2011 at 4:07 PM, Frank Bailey wrote: > I have a question about what is meant by =E2=80=98equivalent=E2=80=99 SA= =E2=80=99s wrt > to rekeying.=C2=A0=C2=A0 If someone has already addressed this, my apolog= ies > and please point to the thread I missed. =E2=80=93 thx. > > In section 2.8 it talks about when rekeying a Child SA or an IKE SA, that > the peers should establish an =E2=80=98equivalent=E2=80=99 SA.=C2=A0 The = question I have, > is what is meant by equivalent?=C2=A0 Does that mean there can only be > one proposal in the SA when rekeying? And, does that proposal have > to match the currently used algorithms for that SA (i.e. the new SA, > must match the SA (as far as transforms) to be rekeyed)? > > In section 2.18, 4th paragraph, it mentions that the =E2=80=98old and new= IKE SA > may have selected a different PRF. =E2=80=A6=E2=80=99=C2=A0=C2=A0=C2=A0 W= hich leads me to think that > we can re-negotiate the transforms during a rekey. My take is that "equivalent SA" means "the same type of SA (IKE or not) with the same traffic selectors and with transforms that are allowed by the policy (SPD)". Think of it this way: suppose you have an extant packet flow (e.g., an open TCP connection) with no traffic, SAs expire, later new outbound traffic triggers the creation of new SAs for that flow's traffic selectors -- if the new SAs meet local policy, then nothing stops their being installed in the SAD and taking effect to protect the packet flow. That is re-keying. If policy allows a range of transforms, then otherwise equivalent SAs remain equivalent even if their transforms differ as long as the transforms are all allowed by policy. Nico -- From frank.bailey@securecommconsulting.com Tue Apr 5 17:09:29 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A28D3A68B1 for ; Tue, 5 Apr 2011 17:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.287 X-Spam-Level: X-Spam-Status: No, score=0.287 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_20=-0.74, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWl+j9UtpUOY for ; Tue, 5 Apr 2011 17:09:28 -0700 (PDT) Received: from mail38.opentransfer.com (mail38.opentransfer.com [76.162.254.38]) by core3.amsl.com (Postfix) with SMTP id 8D7283A6844 for ; Tue, 5 Apr 2011 17:09:28 -0700 (PDT) Received: (qmail 32563 invoked by uid 399); 6 Apr 2011 00:11:11 -0000 Received: from unknown (HELO SecureCommPCfb) (174.79.50.29) by mail38.opentransfer.com with SMTP; 6 Apr 2011 00:11:11 -0000 From: "Frank Bailey" To: References: <2D3A22855517F24E9B960D4D353AABC90A293199E8@DCMS.securecomm.local> In-Reply-To: Date: Tue, 5 Apr 2011 17:11:07 -0700 Message-ID: <000e01cbf3ef$20cdc280$62694780$@bailey@securecommconsulting.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvz6HpM9O4f72AiSgmE9CcSdtambAABnCHg Content-Language: en-us Subject: Re: [IPsec] RFC 5996: IKEv2 - rekey question about 'equivalent' SA's X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 00:09:29 -0000 - thank you, that clears it up. From VSasi@ixiacom.com Tue Apr 5 23:41:36 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCDBC3A688C for ; Tue, 5 Apr 2011 23:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.69 X-Spam-Level: X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qiOxprKzc8f for ; Tue, 5 Apr 2011 23:41:28 -0700 (PDT) Received: from ixqw-mail-out.ixiacom.com (ixqw-mail-out.ixiacom.com [66.77.12.12]) by core3.amsl.com (Postfix) with ESMTP id A9F3E3A68B6 for ; Tue, 5 Apr 2011 23:41:28 -0700 (PDT) Received: from ixcaexch07.ixiacom.com ([fe80:0000:0000:0000:e021:fcf5:238.143.231.20]) by IXCA-HC2.ixiacom.com ([10.200.2.51]) with mapi; Tue, 5 Apr 2011 23:43:12 -0700 From: Vinod Sasi To: "'Scott Fluhrer (sfluhrer)'" , "ipsec@ietf.org" Date: Tue, 5 Apr 2011 23:43:11 -0700 Thread-Topic: [IPsec] Queries relating to ESP/AH GCM & GMAC Thread-Index: AcvznEI7HgmLeLnIR0OYbicIGlj+mgAB5wdgAB+tzAA= Message-ID: <716209EC190CA740BA799AC4ACCBFB5D1851CEE70A@IXCAEXCH07.ixiacom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_716209EC190CA740BA799AC4ACCBFB5D1851CEE70AIXCAEXCH07ixi_" MIME-Version: 1.0 Subject: Re: [IPsec] Queries relating to ESP/AH GCM & GMAC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 06:41:37 -0000 --_000_716209EC190CA740BA799AC4ACCBFB5D1851CEE70AIXCAEXCH07ixi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Scott, Many thanks for your reply; this is helping me to a great extent. Few more clarifications from your reply.. 1.) RFC 4106 talks about Nonce =3D IV + Salt (last 4 bytes of keying ma= terial derived during SA creation). But where do we actually use it in the = context of ESP & AH? I derive the 8-byte IV, feed those 8-bytes as input t= o the GCM Algorithm, take the cipher out & prepend it with the same 8-byte = IV before sending it out on the wire. 2.) Between ESP GMAC & AH GMAC. Please confirm my understanding. a. Plain_text=3DZero for both b. AAD constructed accordingly for ESP & AH outlined in RFC 4303 & 43= 02 c. 8-byte IV is fed to GMAC algorithm for ESP & AH. d. Before being sent over the wire, for ESP the IV is prepended with = the actually payload (IP/TCP/UDP). For AH the IV is prepended with the ICV = tag. e. Both have fixed ICV lengths 3.) Between GCM & GMAC algorithm, only difference being for GMAC the pl= ain_text=3Dzero. So technically a GCM Algorithm code will act as GMAC is my= actually payload length provided as input is zero. Thanks in advance, Vinod -----Original Message----- From: Scott Fluhrer (sfluhrer) [mailto:sfluhrer@cisco.com] Sent: Tuesday, April 05, 2011 9:30 PM To: Vinod Sasi; ipsec@ietf.org Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC Importance: Low From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of V= inod Sasi Sent: Tuesday, April 05, 2011 10:18 AM To: 'ipsec@ietf.org' Subject: [IPsec] Queries relating to ESP/AH GCM & GMAC Hello, I have been reading RFC 4106 & 4543 over the past 2 weeks & in the process = of implementing this RFC for IKEv1 module for my customer. There is a long pending clarification, Appreciate your help on establishing= clarity. 1. What is the scope of Authentication between ESP GMAC & AH GMAC? Shall = I use the understanding outlined in RFC 2401 Section 4.2 Pg 9? I'd use the more detailed descriptions in RFC 4303 and 4302; they define ex= actly what fields are included in the integrity check and (for AH) which fi= elds are considered 'mutable' (and are implicitly replaced by zeros for the= purposes of doing the integrity check). 2. What is the IV mode for GCM & GMAC? How to establish IV synchronizatio= n between the sender & receiver. For (e.g.) AES the IV is placed as the fir= st 16-byte block before Cipher text & sent over the wire. Do I follow the s= ame for GCM/GMAC? It's explained in RFC 4106; the encryptor picks an 8 byte IV, and includes = it in the packet; the decryptor extracts this 8 byte IV from the packet. N= ote that the GCM/GMAC nonce is actually 12 bytes; 8 bytes come from the IV,= and the other 4 bytes come from the keying material ("salt"). Also, important note (RFC 4106 mentions it; it's important enough for me to= reiterate it); it's critical that you never generate two packets with the = same IV (for the same GCM/GMAC key). GCM IVs are not the same as CBC-mode = IVs. With CBC mode, what's important is that the IV be unpredictable (and = so, say, using a random number generator to pick CBC-mode IVs is a good sol= ution). With GCM, it doesn't matter in the slightest if the IV is unpredic= table; what's important is that they never repeat. Randomly picking GCM mo= de IVs will mean that you'll likely to get a repeat after a few billion pac= kets; that'd be bad. Instead, one good way of picking the IVs is to use a c= ounter (you could even reuse the IPSec sequence number if your implementati= on makes that convenient). Some other subtle points: - ESP GMAC is technically a 'combined mode'; what this means is that, = as far as IPSec is concerned, it's both an encryption algorithm and an auth= entication algorithm. It doesn't actually provide confidentiality, but it = is considered an encryption algorithm in the same way that ESP NULL is. On= e implication of that is that it can't be used with, say, ESP AES CBC (just= like you can't use both ESP AES CBC and ESP NULL in the same SA). If you = want both confidentially and integrity, use either ESP-GCM, or AH GMAC and = your favorite ESP encryption algorithm. - AH GMAC and IPv6 has a glitch which I don't think are mentioned expl= icitly in the RFCs; AH is an 'extension header' within IPv6, and the IPv6 R= FC (2460, see section 4) must be a multiple of 8 octets in length. However= , a straight-forward implementation of the AH header with RFC 4543 would yi= eld a 28 octet header (12 octets for the next header/payload length/SPI/seq= no, and 16 octets for the ICV value); 28 is not a multiple of 8. What you = need to do (if you're serious about following the IPv6 RFC) is include an a= dditional 4 octets after the ICV if you're using IPv6. I'd make those 4 oc= tets all zeros; that way, you don't have to worry whether the other side co= nsiders them mutable or not. Thanks in advance, Vinod --_000_716209EC190CA740BA799AC4ACCBFB5D1851CEE70AIXCAEXCH07ixi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Scott,

 

Many thanks for your reply; this is helping me to a great extent.

 

Few more clarifications from your repl= y..

1.)     RFC 4106 talks abou= t Nonce =3D IV + Salt (last 4 bytes of keying material derived during SA crea= tion). But where do we actually use it in the context of ESP & AH?  I der= ive the 8-byte IV, feed those 8-bytes as input to the GCM Algorithm, take the cipher out & prepend it with the same 8-byte IV before sending it out o= n the wire.  

=  

2.)     Between ESP GMAC &a= mp; AH GMAC. Please confirm my understanding.

a.       Plain_text=3DZero f= or both

b.       AAD constructed accordingly for ESP & AH outlined in RFC 4303 & 4302<= /p>

c.       8-byte IV is fed to= GMAC algorithm for ESP & AH.

d.       Before being sent o= ver the wire, for ESP the IV is prepended with the actually payload (IP/TCP/UDP= ). For AH the IV is prepended with the ICV tag.

e.       Both have fixed ICV lengths

=  

3.)     Between GCM & G= MAC algorithm, only difference being for GMAC the plain_text=3Dzero. So technic= ally a GCM Algorithm code will act as GMAC is my actually payload length provided = as input is zero.

=  

Thanks in advance,

Vinod

 

-----Original Message----- From: Scott Fluhrer (sfluhre= r) [mailto:sfluhrer@cisco.com]
Sent: Tuesday, April 05, 201= 1 9:30 PM
To: Vinod Sasi; ipsec@ietf.o= rg
Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC
Importance: Low

 

 

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Vinod Sasi
Sent: Tuesday, April 05, 201= 1 10:18 AM
To: 'ipsec@ietf.org'
Subject: [IPsec] Queries rel= ating to ESP/AH GCM & GMAC

 

Hello,

 

I have been reading= RFC 4106 & 4543 over the past 2 weeks & in the process of implementing = this RFC for IKEv1 module for my customer.

 

There is a long pen= ding clarification, Appreciate your help on establishing clarity.<= /p>

 

1.   What is the scope o= f Authentication between ESP GMAC & AH GMAC? Shall I use the understandin= g outlined in RFC 2401 Section 4.2 Pg 9?

I’d use the more detailed descriptions in RFC 4303 and 4302; they define exactl= y what fields are included in the integrity check and (for AH) which fields a= re considered ‘mutable’ (and are implicitly replaced by zeros for = the purposes of doing the integrity check).

 

 

2.   What is the IV mode= for GCM & GMAC? How to establish IV synchronization between the sender &= ; receiver. For (e.g.) AES the IV is placed as the first 16-byte block before Cipher text & sent over the wire. Do I follow the same for GCM/GMAC?

It’s explained in RFC 4106; the encryptor picks an 8 byte IV, and includes it in= the packet; the decryptor extracts this 8 byte IV from the packet.  Note t= hat the GCM/GMAC nonce is actually 12 bytes; 8 bytes come from the IV, and the other 4 bytes come from the keying material (“salt”).

 

Also, important note (RFC 4106 mentions it; it’s important enough for me to reiterate it); it’s critical that you never generate two packets with= the same IV (for the same GCM/GMAC key).  GCM IVs are not the same as CBC-= mode IVs.  With CBC mode, what’s important is that the IV be unpredictable (and so, say, using a random number generator to pick CBC-mod= e IVs is a good solution).  With GCM, it doesn’t matter in the slightest if the IV is unpredictable; what’s important is that they n= ever repeat.  Randomly picking GCM mode IVs will mean that you’ll lik= ely to get a repeat after a few billion packets; that’d be bad. Instead, = one good way of picking the IVs is to use a counter (you could even reuse the I= PSec sequence number if your implementation makes that convenient).

 

 

Some other subtle points:

= -      ESP GMAC is technically a ‘combined mode’; what this means is that, as far = as IPSec is concerned, it’s both an encryption algorithm and an authentication algorithm.  It doesn’t actually provide confidentiality, but it is considered an encryption algorithm in the same w= ay that ESP NULL is.  One implication of that is that it can’t be u= sed with, say, ESP AES CBC (just like you can’t use both ESP AES CBC and = ESP NULL in the same SA).  If you want both confidentially and integrity, = use either ESP-GCM, or AH GMAC and your favorite ESP encryption algorithm.

= -      AH GMAC and IPv6= has a glitch which I don’t think are mentioned explicitly in the RFCs; AH i= s an ‘extension header’ within IPv6, and the IPv6 RFC (2460, see sec= tion 4) must be a multiple of 8 octets in length.  However, a straight-forw= ard implementation of the AH header with RFC 4543 would yield a 28 octet header= (12 octets for the next header/payload length/SPI/seqno, and 16 octets for the = ICV value); 28 is not a multiple of 8.  What you need to do (if you’= re serious about following the IPv6 RFC) is include an additional 4 octets aft= er the ICV if you’re using IPv6.  I’d make those 4 octets all zeros; that way, you don’t have to worry whether the other side consi= ders them mutable or not.

 

 

Thanks in advance,<= /span>

Vinod=

 

--_000_716209EC190CA740BA799AC4ACCBFB5D1851CEE70AIXCAEXCH07ixi_-- From balaji.1manarmy@gmail.com Wed Apr 6 00:20:57 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6995D3A68BB; Wed, 6 Apr 2011 00:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BziquFES6euk; Wed, 6 Apr 2011 00:20:56 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id E352D3A68BF; Wed, 6 Apr 2011 00:20:55 -0700 (PDT) Received: by qyk7 with SMTP id 7so766478qyk.10 for ; Wed, 06 Apr 2011 00:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=9V89qokl/t+pDxcXZ1Y1BpoclRY1JHidIBj9Fo0+LCg=; b=VG7GWYEqvDT2Wfv8j/0auK+mGu15eYqhdjHop+OUU+NmnfFxlWPXsUvCJ4Q9VTjpXh uJiZcbc+Op2sxR1DMLglfMv+7I30P+YwNh2xviQOnKWQzT1WxUhPFjLBoHZQXbKrCcQ+ 3RpnTIbnOIQ6IgNkMSZDA+QIViF2wYgzQt7gk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KPB6o0uQhTBEIadstc2CkPMV3UF1ZUszJjo+PsveX4DqjXkseW6fzCZIVCc726fXIS OdHnLW3kaV4ffweKiPNviBG0RMNqzfKBNe7CsWZrCNv+kksPcGYMQKUXv23lupsWjAnc tK4bZE78WBEck8OcpduzDZZJNP8R/JNof6pp8= MIME-Version: 1.0 Received: by 10.229.95.144 with SMTP id d16mr499388qcn.37.1302074559322; Wed, 06 Apr 2011 00:22:39 -0700 (PDT) Received: by 10.229.12.145 with HTTP; Wed, 6 Apr 2011 00:22:39 -0700 (PDT) Date: Wed, 6 Apr 2011 12:52:39 +0530 Message-ID: From: Balaji J To: ietf@ietf.org, ipsec@ietf.org Content-Type: multipart/alternative; boundary=001636832048945bcd04a03adb8c Subject: [IPsec] clarification needed in address assignment using IKEv2 Configuration Payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 07:23:55 -0000 --001636832048945bcd04a03adb8c Content-Type: text/plain; charset=ISO-8859-1 Hi ppl, Recently i have started reading the IKEv2 RFC(5996). I need a clarification on assigning the ip address using ikev2 protocol as below which i couldn't find in the RFC4718: Is it valid to assign 0.0.0.0 IP address in the CFG_REPLY paylaod in IKE_AUTH message to the initiator? I need this information for the scenario where the initiator can obtain the IP address by some other means(say DHCP). But still if the initiator needs a secure channel to communicate with the gateway first, before sending the DHCP request for obtaining IP address. Now when the DHCP server provides the IP-address to the initiator, can the SPD be updated updated at that time(by extracting the ip assigned to the initator from the DHCP message) rather than doing the same during the IKE_AUTH response?(as i am thinking of assigning 0.0.0.0 ip during initial IKE_AUTH response in CFG payload) Because when i looked in to RFC4306 under section 2.19(Requesting an Internal Address on a Remote Network) , it says, "Message from responder to initiator: CP(CFG_REPLY)= INTERNAL_ADDRESS(192.0.2.202) INTERNAL_NETMASK(255.255.255.0) INTERNAL_SUBNET( 192.0.2.0/255.255.255.0) TSi = (0, 0-65535,192.0.2.202-192.0.2.202) TSr = (0, 0-65535,192.0.2.0-192.0.2.255) * All returned values will be implementation dependent." There is no mention in RFC something like "assigning 0.0.0.0 should be handled as ERROR". So can i safely say assigning 0.0.0.0 ip address is compliant with RFC? Also section 3.15.4. (Address Assignment Failures) says, "If the initiator does not receive the IP address(es) required by its policy, it MAY keep the IKE SA up and retry the Configuration payload as separate INFORMATIONAL exchange after suitable timeout" Does it mean that the IPSEC-SA cannot be created unless a valid ip is assigned? It is possible to create IPSEC-SA with the traffic-selector alone, rite? why do we need to bother about IP allocation? Assume that there is policy in initiator which says "0.0.0.0 MUST be the ip-address allocated by NAS", then is it valid to send the same in CFG_REPLY payload? Any help is highly appreciated. Thanks, ...Balaji.J --001636832048945bcd04a03adb8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi ppl,

Recently i have started reading the IKEv2 RFC(5996).
I ne= ed a clarification on assigning the ip address using ikev2 protocol as belo= w which i couldn't find in the RFC4718:

Is it valid to assign 0.= 0.0.0 IP address in the CFG_REPLY paylaod in IKE_AUTH message to the initia= tor?
I need this information for the scenario where the initiator can obtain the= IP address by some other means(say DHCP).
But still if the initiator ne= eds a secure channel to communicate with the gateway first, before sending = the DHCP request for obtaining IP address.
Now when the DHCP server provides the IP-address to the initiator,
can t= he SPD be updated updated at that time(by extracting the ip assigned to the= initator from the DHCP message) rather than
doing the same during the I= KE_AUTH response?(as i am thinking of assigning 0.0.0.0 ip during initial I= KE_AUTH response in CFG payload)

Because when i looked in to RFC4306 under section 2.19(Requesting an In= ternal Address on a Remote Network) , it says,
"Message from respon= der to initiator:
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= CP(CFG_REPLY)=3D INTERNAL_ADDRESS(192.0.2.202)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 INTERNAL= _NETMASK(255.255.255.0)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 TSi =3D (0, 0-65535,192.0.2.202-192.0.2.202) =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TSr =3D = (0, 0-65535,192.0.2.0-192.0.2.255)
=A0* All returned values will be impl= ementation dependent."

There is no mention in RFC something lik= e "assigning 0.0.0.0 should be handled as ERROR".
So can i safely say assigning 0.0.0.0 ip address is compliant with RFC?
=
Also section 3.15.4. (Address Assignmen= t Failures) says,
"If the initiator does not receive the IP address= (es) required by its
=A0policy, it MAY keep the IKE SA up and retry the Configuration payload=A0as separate INFORMATIONAL exchange after suitable timeout"

= Does it mean that the IPSEC-SA cannot be created unless a valid ip is assig= ned?
It is possible to create IPSEC-SA with the traffic-selector alone, rite? wh= y do we need to bother about IP allocation?
Assume that there is policy = in initiator which says "0.0.0.0 MUST be the ip-address allocated by N= AS", then is it valid
to send the same in CFG_REPLY payload?

Any= help is highly appreciated.

Thanks,
...Balaji.J

--001636832048945bcd04a03adb8c-- From sfluhrer@cisco.com Wed Apr 6 08:01:26 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5D13A69BB for ; Wed, 6 Apr 2011 08:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDA80TiD4BU3 for ; Wed, 6 Apr 2011 08:01:16 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5280A3A693C for ; Wed, 6 Apr 2011 08:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sfluhrer@cisco.com; l=31866; q=dns/txt; s=iport; t=1302102180; x=1303311780; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=S3dO5r1sNBm+HXxhzNn5edo6ES/32kxF9N98Xvn+7DQ=; b=PsmRrVst7dsj3B6ejauJPrWnzX6fC4X6NOL+H+Nd8y2TV9083TIh/54n 6sna5JNloYl6uugkYt3p71Lz7DLLJV1CwiUbQf2ge+ofg7HaOdncwZgJ+ 2L00RgqIOVoNbAULAj8efwY/4ONQbxPjQHtA/d/Em2o+dm/yxal1AEvui Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYAAJZ/nE2rRDoI/2dsb2JhbACCX5VMjUt3pR+cQIVsBIVOi1c X-IronPort-AV: E=Sophos;i="4.63,310,1299456000"; d="scan'208,217";a="331788407" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 06 Apr 2011 15:03:00 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p36F2xeu025880; Wed, 6 Apr 2011 15:02:59 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 08:02:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AGzN CtPD ESAm Evpd FAT9 GdU/ HNHD HqtW ImN3 KxJ9 Oj3v UwcU Vho7 W6JT W9K/ XAMd; 2; aQBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAdgBzAGEAcwBpAEAAaQB4AGkAYQBjAG8AbQAuAGMAbwBtAA==; Sosha1_v1; 7; {09D9C5A9-B57B-43E1-9F5A-73AC702974C7}; cwBmAGwAdQBoAHIAZQByAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Wed, 06 Apr 2011 15:02:52 GMT; UgBFADoAIABbAEkAUABzAGUAYwBdACAAUQB1AGUAcgBpAGUAcwAgAHIAZQBsAGEAdABpAG4AZwAgAHQAbwAgAEUAUwBQAC8AQQBIACAARwBDAE0AIAAmACAARwBNAEEAQwA= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF46B.B8058AA5" x-cr-puzzleid: {09D9C5A9-B57B-43E1-9F5A-73AC702974C7} Content-class: urn:content-classes:message Date: Wed, 6 Apr 2011 08:02:52 -0700 Message-ID: In-Reply-To: <716209EC190CA740BA799AC4ACCBFB5D1851CEE70A@IXCAEXCH07.ixiacom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Queries relating to ESP/AH GCM & GMAC Thread-Index: AcvznEI7HgmLeLnIR0OYbicIGlj+mgAB5wdgAB+tzAAAEWV5kA== References: <716209EC190CA740BA799AC4ACCBFB5D1851CEE70A@IXCAEXCH07.ixiacom.com> From: "Scott Fluhrer (sfluhrer)" To: "Vinod Sasi" , X-OriginalArrivalTime: 06 Apr 2011 15:02:59.0788 (UTC) FILETIME=[B81E90C0:01CBF46B] Subject: Re: [IPsec] Queries relating to ESP/AH GCM & GMAC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:01:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF46B.B8058AA5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 From: Vinod Sasi [mailto:VSasi@ixiacom.com]=20 Sent: Wednesday, April 06, 2011 2:43 AM To: Scott Fluhrer (sfluhrer); ipsec@ietf.org Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC =20 Hello Scott, =20 Many thanks for your reply; this is helping me to a great extent.=20 =20 Few more clarifications from your reply.. 1.) RFC 4106 talks about Nonce =3D IV + Salt (last 4 bytes of keying material derived during SA creation). But where do we actually use it in the context of ESP & AH? I derive the 8-byte IV, feed those 8-bytes as input to the GCM Algorithm, take the cipher out & prepend it with the same 8-byte IV before sending it out on the wire. You feed the 12 byte nonce as input to the GCM algorithm, not the 8 byte IV. =20 =20 2.) Between ESP GMAC & AH GMAC. Please confirm my understanding. a. Plain_text=3DZero for both By zero, I assume you mean the empty string. =20 b. AAD constructed accordingly for ESP & AH outlined in RFC 4303 & 4302 c. 8-byte IV is fed to GMAC algorithm for ESP & AH. 12 byte nonce. =20 d. Before being sent over the wire, for ESP the IV is prepended with the actually payload (IP/TCP/UDP). For AH the IV is prepended with the ICV tag. Actually, for ESP GMAC, this step needs to happen before (b), because the IV is included in the AAD (the region being authenticated). For AH GMAC, the IV is part of a mutable section, so either order would work. =20 e. Both have fixed ICV lengths Yes, that is correct. Now, the ESP-GCM transform does have variable ICV lengths (8, 12, 16 octets); I'd strongly advise everyone to use the 16 octet length; there are known security problems if you truncate the ICV. =20 3.) Between GCM & GMAC algorithm, only difference being for GMAC the plain_text=3Dzero. No, another difference is that the AAD are constructed differently. =20 So technically a GCM Algorithm code will act as GMAC is my actually payload length provided as input is zero. A general purpose GCM (the cryptographical algorithm) implementation should be able to perform the computations for the ESP GCM, ESP GMAC and AH GMAC IPsec transforms; however, the AAD and plaintext/ciphertext inputs would differ. =20 =20 Thanks in advance, Vinod =20 -----Original Message----- From: Scott Fluhrer (sfluhrer) [mailto:sfluhrer@cisco.com]=20 Sent: Tuesday, April 05, 2011 9:30 PM To: Vinod Sasi; ipsec@ietf.org Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC Importance: Low =20 =20 =20 From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Vinod Sasi Sent: Tuesday, April 05, 2011 10:18 AM To: 'ipsec@ietf.org' Subject: [IPsec] Queries relating to ESP/AH GCM & GMAC =20 Hello, =20 I have been reading RFC 4106 & 4543 over the past 2 weeks & in the process of implementing this RFC for IKEv1 module for my customer.=20 =20 There is a long pending clarification, Appreciate your help on establishing clarity. =20 1. What is the scope of Authentication between ESP GMAC & AH GMAC? Shall I use the understanding outlined in RFC 2401 Section 4.2 Pg 9? I'd use the more detailed descriptions in RFC 4303 and 4302; they define exactly what fields are included in the integrity check and (for AH) which fields are considered 'mutable' (and are implicitly replaced by zeros for the purposes of doing the integrity check). =20 =20 2. What is the IV mode for GCM & GMAC? How to establish IV synchronization between the sender & receiver. For (e.g.) AES the IV is placed as the first 16-byte block before Cipher text & sent over the wire. Do I follow the same for GCM/GMAC? It's explained in RFC 4106; the encryptor picks an 8 byte IV, and includes it in the packet; the decryptor extracts this 8 byte IV from the packet. Note that the GCM/GMAC nonce is actually 12 bytes; 8 bytes come from the IV, and the other 4 bytes come from the keying material ("salt"). =20 Also, important note (RFC 4106 mentions it; it's important enough for me to reiterate it); it's critical that you never generate two packets with the same IV (for the same GCM/GMAC key). GCM IVs are not the same as CBC-mode IVs. With CBC mode, what's important is that the IV be unpredictable (and so, say, using a random number generator to pick CBC-mode IVs is a good solution). With GCM, it doesn't matter in the slightest if the IV is unpredictable; what's important is that they never repeat. Randomly picking GCM mode IVs will mean that you'll likely to get a repeat after a few billion packets; that'd be bad. Instead, one good way of picking the IVs is to use a counter (you could even reuse the IPSec sequence number if your implementation makes that convenient). =20 =20 Some other subtle points: - ESP GMAC is technically a 'combined mode'; what this means is that, as far as IPSec is concerned, it's both an encryption algorithm and an authentication algorithm. It doesn't actually provide confidentiality, but it is considered an encryption algorithm in the same way that ESP NULL is. One implication of that is that it can't be used with, say, ESP AES CBC (just like you can't use both ESP AES CBC and ESP NULL in the same SA). If you want both confidentially and integrity, use either ESP-GCM, or AH GMAC and your favorite ESP encryption algorithm. - AH GMAC and IPv6 has a glitch which I don't think are mentioned explicitly in the RFCs; AH is an 'extension header' within IPv6, and the IPv6 RFC (2460, see section 4) must be a multiple of 8 octets in length. However, a straight-forward implementation of the AH header with RFC 4543 would yield a 28 octet header (12 octets for the next header/payload length/SPI/seqno, and 16 octets for the ICV value); 28 is not a multiple of 8. What you need to do (if you're serious about following the IPv6 RFC) is include an additional 4 octets after the ICV if you're using IPv6. I'd make those 4 octets all zeros; that way, you don't have to worry whether the other side considers them mutable or not. =20 =20 Thanks in advance, Vinod =20 ------_=_NextPart_001_01CBF46B.B8058AA5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= Vinod Sasi [mailto:VSasi@ixiacom.com]
Sent: Wednesday, April 06, 2011 2:43 AM
To: Scott Fluhrer (sfluhrer); ipsec@ietf.org
Subject: RE: [IPsec] Queries relating to ESP/AH GCM & = GMAC

 

Hello Scott,

 

Many thanks for your reply; this is helping me to a great = extent.

 

Few more clarifications from your = reply..

1.)   RFC 4106 talks about Nonce =3D IV + Salt (last 4 bytes of = keying material derived during SA creation). But where do we actually use it in = the context of ESP & AH?  I derive the 8-byte IV, feed those = 8-bytes as input to the GCM Algorithm, take the cipher out & prepend it with = the same 8-byte IV before sending it out on the wire.

You feed the 12 byte nonce as input to the GCM algorithm, = not the 8 byte IV.

  

 

=

2.= )     = Be= tween ESP GMAC & AH GMAC. Please confirm my = understanding.

a.=       = Pl= ain_text=3DZero for both

By zero, I assume you mean the empty = string.

 

b.=       = AA= D constructed accordingly for ESP & AH outlined in RFC 4303 & = 4302

c.=       = 8-= byte IV is fed to GMAC algorithm for ESP & AH.

12 byte nonce.

 

d.=       = Be= fore being sent over the wire, for ESP the IV is prepended with the actually = payload (IP/TCP/UDP). For AH the IV is prepended with the ICV tag.

Actually, for ESP GMAC, this step needs to happen before = (b), because the IV is included in the AAD (the region being authenticated). =   For AH GMAC, the IV is part of a mutable section, so either order would = work.

 

e.=       = Bo= th have fixed ICV lengths

Yes, that is correct.  Now, the ESP-GCM transform does = have variable ICV lengths (8, 12, 16 octets); I’d strongly advise = everyone to use the 16 octet length; there are known security problems if you = truncate the ICV.

 

=

3.= )     = Be= tween GCM & GMAC algorithm, only difference being for GMAC the = plain_text=3Dzero.

No, another difference is that the AAD are constructed = differently.

 

So= technically a GCM Algorithm code will act as GMAC is my actually payload = length provided as input is zero.

A general purpose GCM (the cryptographical algorithm) = implementation should be able to perform the computations for the ESP GCM, ESP GMAC and = AH GMAC IPsec transforms; however, the AAD and plaintext/ciphertext inputs = would differ.

 

 

=

Thanks in advance,

Vinod

 

-----Original Message-----
From: Scott Fluhrer (sfluhrer) [mailto:sfluhrer@cisco.com]
Sent: Tuesday, April 05, 2011 9:30 PM
To: Vinod Sasi; ipsec@ietf.org
Subject: RE: [IPsec] Queries relating to ESP/AH GCM & = GMAC
Importance: Low

 

 

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Vinod Sasi
Sent: Tuesday, April 05, 2011 10:18 AM
To: 'ipsec@ietf.org'
Subject: [IPsec] Queries relating to ESP/AH GCM & = GMAC

 

Hello,

=

 

=

I have been reading RFC = 4106 & 4543 over the past 2 weeks & in the process of implementing this RFC = for IKEv1 module for my customer.

 

=

There is a long pending clarification, Appreciate your help on establishing = clarity.

 

=

1.   What is the scope of Authentication between ESP GMAC & = AH GMAC? Shall I use the understanding outlined in RFC 2401 Section 4.2 Pg = 9?

I’d use the more = detailed descriptions in RFC 4303 and 4302; they define exactly what fields are = included in the integrity check and (for AH) which fields are considered ‘mutable’ (and are implicitly replaced by zeros for the = purposes of doing the integrity check).

 

 

2.   What is the IV mode for GCM & GMAC? How to establish IV synchronization between the sender & receiver. For (e.g.) AES the IV = is placed as the first 16-byte block before Cipher text & sent over the = wire. Do I follow the same for GCM/GMAC?

It’s explained in = RFC 4106; the encryptor picks an 8 byte IV, and includes it in the packet; = the decryptor extracts this 8 byte IV from the packet.  Note that the = GCM/GMAC nonce is actually 12 bytes; 8 bytes come from the IV, and the other 4 = bytes come from the keying material = (“salt”).

 <= /p>

Also, important note = (RFC 4106 mentions it; it’s important enough for me to reiterate it); = it’s critical that you never generate two packets with the same IV (for the = same GCM/GMAC key).  GCM IVs are not the same as CBC-mode IVs.  = With CBC mode, what’s important is that the IV be unpredictable (and so, = say, using a random number generator to pick CBC-mode IVs is a good = solution).  With GCM, it doesn’t matter in the slightest if the IV is = unpredictable; what’s important is that they never repeat.  Randomly picking = GCM mode IVs will mean that you’ll likely to get a repeat after a few = billion packets; that’d be bad. Instead, one good way of picking the IVs = is to use a counter (you could even reuse the IPSec sequence number if your implementation makes that convenient).

 <= /p>

 <= /p>

Some other subtle = points:

-      = ESP GMAC is technically a ‘combined mode’; what this means is = that, as far as IPSec is concerned, it’s both an encryption algorithm and = an authentication algorithm.  It doesn’t actually provide confidentiality, but it is considered an encryption algorithm in the = same way that ESP NULL is.  One implication of that is that it can’t = be used with, say, ESP AES CBC (just like you can’t use both ESP AES CBC = and ESP NULL in the same SA).  If you want both confidentially and = integrity, use either ESP-GCM, or AH GMAC and your favorite ESP encryption = algorithm.

-      = AH GMAC and IPv6 has a glitch which I don’t think are mentioned explicitly = in the RFCs; AH is an ‘extension header’ within IPv6, and the IPv6 = RFC (2460, see section 4) must be a multiple of 8 octets in length.  = However, a straight-forward implementation of the AH header with RFC 4543 would = yield a 28 octet header (12 octets for the next header/payload length/SPI/seqno, = and 16 octets for the ICV value); 28 is not a multiple of 8.  What you = need to do (if you’re serious about following the IPv6 RFC) is include an = additional 4 octets after the ICV if you’re using IPv6.  I’d make = those 4 octets all zeros; that way, you don’t have to worry whether the = other side considers them mutable or not.

 <= /p>

 

=

Thanks in = advance,

Vinod

 

------_=_NextPart_001_01CBF46B.B8058AA5-- From tena@huawei.com Wed Apr 6 12:19:43 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FAB33A6405 for ; Wed, 6 Apr 2011 12:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.28 X-Spam-Level: X-Spam-Status: No, score=-106.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsaOplrPaB+f for ; Wed, 6 Apr 2011 12:19:41 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id CC0993A63EB for ; Wed, 6 Apr 2011 12:19:41 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ8004LAWFP6N@usaga02-in.huawei.com> for ipsec@ietf.org; Wed, 06 Apr 2011 12:21:25 -0700 (PDT) Received: from TingZousc1 ([10.212.245.80]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJ800GGVWFO14@usaga02-in.huawei.com> for ipsec@ietf.org; Wed, 06 Apr 2011 12:21:25 -0700 (PDT) Date: Wed, 06 Apr 2011 12:21:24 -0700 From: Tina Tsou To: 'Nico Williams' Message-id: <00fc01cbf48f$d246ff40$76d4fdc0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acv0j9G67Zs72qLPQWqPhQ0T8Ha1Rw== Cc: ipsec@ietf.org, frank.bailey@securecommconsulting.com Subject: Re: [IPsec] RFC 5996: IKEv2 - rekey question about 'equivalent' SA's X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 19:19:43 -0000 Hi Nico, I thought about rekeying problem when the software lifetime expires. If two security gateway to initiate rekeying, what is the additional benefit brought to IKE? We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Nico Williams Sent: Tuesday, April 05, 2011 4:23 PM To: Frank Bailey Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC 5996: IKEv2 - rekey question about 'equivalent' SA's On Tue, Apr 5, 2011 at 4:07 PM, Frank Bailey wrote: > I have a question about what is meant by 'equivalent' SA's wrt > to rekeying. If someone has already addressed this, my apologies > and please point to the thread I missed. - thx. > > In section 2.8 it talks about when rekeying a Child SA or an IKE SA, that > the peers should establish an 'equivalent' SA. The question I have, > is what is meant by equivalent? Does that mean there can only be > one proposal in the SA when rekeying? And, does that proposal have > to match the currently used algorithms for that SA (i.e. the new SA, > must match the SA (as far as transforms) to be rekeyed)? > > In section 2.18, 4th paragraph, it mentions that the 'old and new IKE SA > may have selected a different PRF. .' Which leads me to think that > we can re-negotiate the transforms during a rekey. My take is that "equivalent SA" means "the same type of SA (IKE or not) with the same traffic selectors and with transforms that are allowed by the policy (SPD)". Think of it this way: suppose you have an extant packet flow (e.g., an open TCP connection) with no traffic, SAs expire, later new outbound traffic triggers the creation of new SAs for that flow's traffic selectors -- if the new SAs meet local policy, then nothing stops their being installed in the SAD and taking effect to protect the packet flow. That is re-keying. If policy allows a range of transforms, then otherwise equivalent SAs remain equivalent even if their transforms differ as long as the transforms are all allowed by policy. Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Thu Apr 7 05:29:01 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB4F3A6A0B for ; Thu, 7 Apr 2011 05:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.858 X-Spam-Level: X-Spam-Status: No, score=-101.858 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJLNcNZENdQj for ; Thu, 7 Apr 2011 05:29:00 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC8D3A6920 for ; Thu, 7 Apr 2011 05:29:00 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p36C3pqm027457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2011 15:03:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p36C3pbJ022045; Wed, 6 Apr 2011 15:03:51 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19868.22183.35956.708462@fireball.kivinen.iki.fi> Date: Wed, 6 Apr 2011 15:03:51 +0300 From: Tero Kivinen To: Balaji J In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 18 min Cc: ipsec@ietf.org Subject: [IPsec] clarification needed in address assignment using IKEv2 Configuration Payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 12:29:01 -0000 Balaji J writes: > Recently i have started reading the IKEv2 RFC(5996). > I need a clarification on assigning the ip address using ikev2 protocol as > below which i couldn't find in the RFC4718: Note that RFC5996 is more resent than RFC4718 and RFC5996 obsoletes both RFC4306 and RFC4718, so not all RFC4718 text is correct anymore. We did include most of the things from the RFC4718 to the RFC5996. > Is it valid to assign 0.0.0.0 IP address in the CFG_REPLY paylaod in > IKE_AUTH message to the initiator? I do not think there is anything that would explictly prohibit it, but I would expect most implementations would then try to configure that ip-address to be used, and that will cause problems. It would be better not to do that if you want interoperate with other implementations. > I need this information for the scenario where the initiator can obtain the > IP address by some other means(say DHCP). > But still if the initiator needs a secure channel to communicate with the > gateway first, before sending the DHCP request for obtaining IP address. I would say then it would be better to not to return any IP-address to the client. See section 3.15.4 of RFC5996 for more information. One of the ways to fail address assignment failures is to return with CFG_REPLY but without INTERNAL_IP*_ADDRESS. > Now when the DHCP server provides the IP-address to the initiator, > can the SPD be updated updated at that time(by extracting the ip assigned to > the initator from the DHCP message) rather than > doing the same during the IKE_AUTH response?(as i am thinking of assigning > 0.0.0.0 ip during initial IKE_AUTH response in CFG payload) That is local implementation matter. If you are assuming IP-address allocation is done in the DHCP over the IPsec tunnel, and your gateway does DHCP-packet snoopping on the link, it can modify the SPD based on that snooping. What you are doing sounds a bit like what RFC3456 did for IKEv1. > Because when i looked in to RFC4306 under section 2.19(Requesting an > Internal Address on a Remote Network) , it says, > "Message from responder to initiator: > CP(CFG_REPLY)= INTERNAL_ADDRESS(192.0.2.202) > > INTERNAL_NETMASK(255.255.255.0) > INTERNAL_SUBNET( > 192.0.2.0/255.255.255.0) > TSi = (0, > 0-65535,192.0.2.202-192.0.2.202) > TSr = (0, > 0-65535,192.0.2.0-192.0.2.255) > * All returned values will be implementation dependent." > > There is no mention in RFC something like "assigning 0.0.0.0 should be > handled as ERROR". > So can i safely say assigning 0.0.0.0 ip address is compliant with RFC? I would say yes, but do not expect it to work on generic implementations... > Also section 3.15.4. (Address Assignment Failures) says, > "If the initiator does not receive the IP address(es) required by its > policy, it MAY keep the IKE SA up and retry the Configuration payload > as separate INFORMATIONAL exchange after suitable timeout" > > Does it mean that the IPSEC-SA cannot be created unless a valid ip is > assigned? It depends. To send some packets over IPsec you need valid IP address. It is possible that some implementations will happily configure 0.0.0.0 as their IP-address and use that. On the other hand some implementations might simply do something different. > It is possible to create IPSEC-SA with the traffic-selector alone, rite? why > do we need to bother about IP allocation? Yes. That is possible. You do not need to allocate IP-addresses using configuration mode at all during the IKE_AUTH. That is optional feature of the IKEv2. > Assume that there is policy in initiator which says "0.0.0.0 MUST be > the ip-address allocated by NAS", then is it valid to send the same > in CFG_REPLY payload? If the initiator assumes that kind of setup, it is easier simply just skip Configuration payloads completely, and just create wildcard IPsec SA and use that for doing the DHCP. -- kivinen@iki.fi From kivinen@iki.fi Thu Apr 7 05:29:02 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA7F3A6A0B for ; Thu, 7 Apr 2011 05:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgVuHwbH19OG for ; Thu, 7 Apr 2011 05:29:02 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1423A690C for ; Thu, 7 Apr 2011 05:29:01 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p36BO3ft002915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2011 14:24:03 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p36BO2YB002960; Wed, 6 Apr 2011 14:24:02 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19868.19794.492823.292222@fireball.kivinen.iki.fi> Date: Wed, 6 Apr 2011 14:24:02 +0300 From: Tero Kivinen To: Frank Bailey In-Reply-To: <2D3A22855517F24E9B960D4D353AABC90A293199E8@DCMS.securecomm.local> References: <2D3A22855517F24E9B960D4D353AABC90A293199E8@DCMS.securecomm.local> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 11 min Cc: "ipsec@ietf.org" Subject: [IPsec] RFC 5996: IKEv2 - rekey question about 'equivalent' SA's X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 12:29:03 -0000 Frank Bailey writes: > In section 2.8 it talks about when rekeying a Child SA or an IKE SA, that > the peers should establish an 'equivalent' SA. The question I have, > is what is meant by equivalent? It means mostly same... I.e. protecting same traffic and using same parameters, ciphers etc. > Does that mean there can only be one proposal in the SA when > rekeying? As the RFC5996 says that traffic selectors and algorithms SHOULD NOT be different, there is no point of including more than one proposal. The best is just to propose exactly same algorithms, and traffic selectors which are used by the Child SA you are rekeying. > And, does that proposal have to match the currently used algorithms > for that SA (i.e. the new SA, must match the SA (as far as > transforms) to be rekeyed)? The RFC5996 has "SHOULD" for that, so unless you have good reasons (which you can explain) why you are not following that SHOULD then that is the way to go. > In section 2.18, 4th paragraph, it mentions that the 'old and new IKE SA > may have selected a different PRF. ...' Which leads me to think that > we can re-negotiate the transforms during a rekey. This is for IKE SA rekey. The crypt algorithms and traffic selectors "SHOULD" in the RFC5996 only applies to the Child SAs. For the IKE SA there is no suggestion that you need to keep ciphers same. The reason for why the algorithms SHOULD NOT change during the Child SA rekey is that on some implementation or on some hardware the rekey is optimized so that the newly created Child SA does not really allocate new full SA, but instead the newly rekeyed SA is added to the existing SA with some new parameters (i.e SPI and keying material). Then when the old SA is deleted the rekeyed SA is moved to be the primary SA of this kind of bundle. This is done so that the statistics and so on can be kept over the SA rekeys etc. This is purely local implementation issue and this kind of optimization quite often share lots of data with the previous SA, and those shared data can and often will include algoritms and the traffic selectors. So following that SHOULD NOT allows more efficient use of resources on some implementations. Of course most likely those implementation will enforce this by always picking the same set of algorithms the are already using on the old SA if they have been proposed multiple algorithms. On the other hand if the proposed set does not include currently used crypto algorithms, those implementations might return error like NO_PROPOSAL_CHOSEN for the rekey attempts, even when similar alrogithm set could be used to create SA from the scratch. This might cause the situation where the host A tries to rekey and host B always says NO_PROPOSAL_CHOSEN and finally the Child SA expires, and then it is created again from the beginning (i.e. no rekey) and then it succeeds, meaning that this setup still works, but is not as optimized as it could be and it might cause few packets to be lost during the operation. -- kivinen@iki.fi From kivinen@iki.fi Thu Apr 7 05:29:04 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B590C28C122 for ; Thu, 7 Apr 2011 05:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mrQNLr6FFlz for ; Thu, 7 Apr 2011 05:29:03 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C5C513A6920 for ; Thu, 7 Apr 2011 05:29:02 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p36BiUYe016546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2011 14:44:30 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p36BiTJC003068; Wed, 6 Apr 2011 14:44:29 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19868.21021.903247.236756@fireball.kivinen.iki.fi> Date: Wed, 6 Apr 2011 14:44:29 +0300 From: Tero Kivinen To: Vinod Sasi In-Reply-To: <716209EC190CA740BA799AC4ACCBFB5D1851CEE70A@IXCAEXCH07.ixiacom.com> References: <716209EC190CA740BA799AC4ACCBFB5D1851CEE70A@IXCAEXCH07.ixiacom.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 20 min Cc: "ipsec@ietf.org" , "'Scott Fluhrer \(sfluhrer\)'" Subject: Re: [IPsec] Queries relating to ESP/AH GCM & GMAC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 12:29:04 -0000 Vinod Sasi writes: > Many thanks for your reply; this is helping me to a great extent. In the RFC6071 we do note that those combined mode ciphers are not feature of the old IPsec-v2 set (i.e IKEv1). I would recommend not to implement them using IKEv1, as there might be quite a lot of interoperability issues, especially as the documentation how to use them in IKEv1 is non-existing and different implementations might use different interpretation how some document text should be applied in this context. The text in the RFC6071 (IPsec Roadmap) says: ---------------------------------------------------------------------- 5.4. Combined Mode Algorithms IKEv1 and ESP-v2 use separate algorithms to provide encryption and integrity protection, and IKEv1 can negotiate different combinations of algorithms for different SAs. In ESP-v3, a new class of algorithms was introduced, in which a single algorithm can provide both encryption and integrity protection. [RFC5996] describes how IKEv2 can negotiate combined mode algorithms to be used in ESP-v3 SAs. [RFC5282] adds that capability to IKEv2, enabling IKEv2 to negotiate and use combined mode algorithms for its own traffic. When properly designed, these algorithms can provide increased efficiency in both implementation and execution. Although ESP-v2 did not originally include combined mode algorithms, some IKEv1 implementations have added the capability to negotiate combined mode algorithms for use in IPsec SAs; these implementations do not include the capability to use combined mode algorithms to protect IKE SAs. IANA numbers for combined mode algorithms have been added to the IKEv1 registry. ... 5.4.2. RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) (S, June 2005) ... Requirement levels for AES-GCM: IKEv1 - N/A IKEv2 - optional ESP-v2 - N/A ESP-v3 - optional [RFC4835] NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol. ---------------------------------------------------------------------- So unless this feature is really needed for some internal use case, I would recommend using IKEv2 instead. Do not expect this feature to be interoperable with other IPsec implementations unless you specifically test it. > Few more clarifications from your reply.. > 1.) RFC 4106 talks about Nonce = IV + Salt (last 4 bytes of > keying material derived during SA creation). But where do we > actually use it in the context of ESP & AH? I derive the 8-byte IV, > feed those 8-bytes as input to the GCM Algorithm, take the cipher > out & prepend it with the same 8-byte IV before sending it out on > the wire. RFC4303 explains how you use combined mode ciphers in the ESPv3. You cannot use combined mode ciphers in the RFC2406 implementations. > 2.) Between ESP GMAC & AH GMAC. Please confirm my understanding. You mean RFC4543? > a. Plain_text=Zero for both > b. AAD constructed accordingly for ESP & AH outlined in RFC 4303 & 4302 The AAD is constructed as specified in RFC4543 section 3.3 > c. 8-byte IV is fed to GMAC algorithm for ESP & AH. Yes. > d. Before being sent over the wire, for ESP the IV is > prepended with the actually payload (IP/TCP/UDP). For AH the IV is > prepended with the ICV tag. In the ESP the IV is stored in the IV field of the RFC 4303 section 2. In the AH the IV is part of the ICV field of the RFC4302 section 2 and the construction of the ICV field is specified in the RFC4543 section 4. > e. Both have fixed ICV lengths No. RFC4106 has 3 different ICV lengths. RFC4543 has only one. > 3.) Between GCM & GMAC algorithm, only difference being for GMAC the > plain_text=zero. So technically a GCM Algorithm code will act as > GMAC is my actually payload length provided as input is zero. RFC4543 says section 3.5 says: ---------------------------------------------------------------------- 3.5. Differences with AES-GCM-ESP In this section, we highlight the differences between this specification and AES-GCM-ESP [RFC4106]. The essential difference is that in this document, the AAD consists of the SPI, Sequence Number, and ESP Payload, and the AES-GCM plaintext is zero-length, while in AES-GCM-ESP, the AAD consists only of the SPI and Sequence Number, and the AES-GCM plaintext consists of the ESP Payload. These differences are illustrated in Figure 4. This figure shows the case in which the Extended Sequence Number option is not used. When that option is exercised, the Sequence Number field in the figure would be replaced with the Extended Sequence Number. Importantly, ENCR_NULL_AUTH_AES_GMAC is *not* equivalent to AES-GCM- ESP with encryption "turned off". However, the ICV computations performed in both cases are similar because of the structure of the GHASH function [GCM]. ... -- kivinen@iki.fi From david.black@emc.com Thu Apr 7 06:45:40 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0A93A69BD for ; Thu, 7 Apr 2011 06:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.586 X-Spam-Level: X-Spam-Status: No, score=-106.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62GVVWW7SKtD for ; Thu, 7 Apr 2011 06:45:39 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 09F723A692A for ; Thu, 7 Apr 2011 06:45:38 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p37DlFCP028606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Apr 2011 09:47:18 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 7 Apr 2011 09:47:07 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.221.47.158]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p37DihmD019694; Thu, 7 Apr 2011 09:45:44 -0400 Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub29.corp.emc.com ([128.221.47.158]) with mapi; Thu, 7 Apr 2011 09:45:25 -0400 From: To: Date: Thu, 7 Apr 2011 09:45:23 -0400 Thread-Topic: [IPsec] Queries relating to ESP/AH GCM & GMAC Thread-Index: Acv1IHxzokiKT8qKRcOB3RzT/jmIFAABlvfg Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5EF280B@MX14A.corp.emc.com> References: <716209EC190CA740BA799AC4ACCBFB5D1851CEE70A@IXCAEXCH07.ixiacom.com> <19868.21021.903247.236756@fireball.kivinen.iki.fi> In-Reply-To: <19868.21021.903247.236756@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: ipsec@ietf.org Subject: Re: [IPsec] Queries relating to ESP/AH GCM & GMAC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 13:45:40 -0000 Here's a little more explanation of this text from RFC 6071: > Although ESP-v2 did not originally include combined mode algorithms, > some IKEv1 implementations have added the capability to negotiate > combined mode algorithms for use in IPsec SAs; these implementations > do not include the capability to use combined mode algorithms to > protect IKE SAs. IANA numbers for combined mode algorithms have been > added to the IKEv1 registry. It's more than a decision to not include that capability - IKEv1 exchanges cannot be protected with combined mode algorithms without significant incompatible change to IKEv1, as explained in Section 1 of RFC 5282: Version 1 of the Internet Key Exchange protocol (IKEv1) [RFC2409] is based on the Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408]. The E (Encryption) bit in the ISAKMP header specifies that all payloads following the header are encrypted, but any data integrity verification of those payloads is handled by a separate Hash Payload or Signature Payload (see Sections 3.1, 3.11, and 3.12 of [RFC2408]). This separation of encryption from data integrity protection prevents the use of authenticated encryption with IKEv1, thus limiting initial specifications of AES combined mode usage for IPsec to the Encapsulating Security Payload (ESP) [RFC2406]. OTOH, RFC 4106 (GCM), RFC 4309 (CCM), and RFC 4543 (GMAC) were written in a fashion that allowed their use with ESP (RFC 2406) to be negotiated by IKEv1 (and also for AH in the case of GMAC). I would strongly object to removal of the IANA registry entries that support this usage, although I agree that everyone should be using IKEv2 in preference to IKEv1. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of= Tero Kivinen > Sent: Wednesday, April 06, 2011 7:44 AM > To: Vinod Sasi > Cc: ipsec@ietf.org; 'Scott Fluhrer (sfluhrer)' > Subject: Re: [IPsec] Queries relating to ESP/AH GCM & GMAC >=20 > Vinod Sasi writes: > > Many thanks for your reply; this is helping me to a great extent. >=20 > In the RFC6071 we do note that those combined mode ciphers are not > feature of the old IPsec-v2 set (i.e IKEv1). I would recommend not to > implement them using IKEv1, as there might be quite a lot of > interoperability issues, especially as the documentation how to use > them in IKEv1 is non-existing and different implementations might use > different interpretation how some document text should be applied in > this context. >=20 > The text in the RFC6071 (IPsec Roadmap) says: >=20 > ---------------------------------------------------------------------- > 5.4. Combined Mode Algorithms >=20 > IKEv1 and ESP-v2 use separate algorithms to provide encryption and > integrity protection, and IKEv1 can negotiate different combinations > of algorithms for different SAs. In ESP-v3, a new class of > algorithms was introduced, in which a single algorithm can provide > both encryption and integrity protection. [RFC5996] describes how > IKEv2 can negotiate combined mode algorithms to be used in ESP-v3 > SAs. [RFC5282] adds that capability to IKEv2, enabling IKEv2 to > negotiate and use combined mode algorithms for its own traffic. When > properly designed, these algorithms can provide increased efficiency > in both implementation and execution. >=20 > Although ESP-v2 did not originally include combined mode algorithms, > some IKEv1 implementations have added the capability to negotiate > combined mode algorithms for use in IPsec SAs; these implementations > do not include the capability to use combined mode algorithms to > protect IKE SAs. IANA numbers for combined mode algorithms have been > added to the IKEv1 registry. > ... > 5.4.2. RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec > Encapsulating Security Payload (ESP) (S, June 2005) > ... > Requirement levels for AES-GCM: >=20 > IKEv1 - N/A > IKEv2 - optional > ESP-v2 - N/A > ESP-v3 - optional [RFC4835] >=20 > NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but > combined mode algorithms are not a feature of IPsec-v2. Although > some IKEv1/IPsec-v2 implementations include this capability (see > Section 5.4), it is not part of the protocol. > ---------------------------------------------------------------------- >=20 > So unless this feature is really needed for some internal use case, I > would recommend using IKEv2 instead. >=20 > Do not expect this feature to be interoperable with other IPsec > implementations unless you specifically test it. >=20 > > Few more clarifications from your reply.. > > 1.) RFC 4106 talks about Nonce =3D IV + Salt (last 4 bytes of > > keying material derived during SA creation). But where do we > > actually use it in the context of ESP & AH? I derive the 8-byte IV, > > feed those 8-bytes as input to the GCM Algorithm, take the cipher > > out & prepend it with the same 8-byte IV before sending it out on > > the wire. >=20 > RFC4303 explains how you use combined mode ciphers in the ESPv3. You > cannot use combined mode ciphers in the RFC2406 implementations. >=20 > > 2.) Between ESP GMAC & AH GMAC. Please confirm my understanding. >=20 > You mean RFC4543? >=20 > > a. Plain_text=3DZero for both > > b. AAD constructed accordingly for ESP & AH outlined in RFC 4303 = & 4302 >=20 > The AAD is constructed as specified in RFC4543 section 3.3 >=20 > > c. 8-byte IV is fed to GMAC algorithm for ESP & AH. >=20 > Yes. >=20 > > d. Before being sent over the wire, for ESP the IV is > > prepended with the actually payload (IP/TCP/UDP). For AH the IV is > > prepended with the ICV tag. >=20 > In the ESP the IV is stored in the IV field of the RFC 4303 section 2. >=20 > In the AH the IV is part of the ICV field of the RFC4302 section 2 and > the construction of the ICV field is specified in the RFC4543 section > 4. >=20 > > e. Both have fixed ICV lengths >=20 > No. RFC4106 has 3 different ICV lengths. RFC4543 has only one. >=20 > > 3.) Between GCM & GMAC algorithm, only difference being for GMAC the > > plain_text=3Dzero. So technically a GCM Algorithm code will act as > > GMAC is my actually payload length provided as input is zero. >=20 > RFC4543 says section 3.5 says: >=20 > ---------------------------------------------------------------------- > 3.5. Differences with AES-GCM-ESP >=20 > In this section, we highlight the differences between this > specification and AES-GCM-ESP [RFC4106]. The essential difference is > that in this document, the AAD consists of the SPI, Sequence Number, > and ESP Payload, and the AES-GCM plaintext is zero-length, while in > AES-GCM-ESP, the AAD consists only of the SPI and Sequence Number, > and the AES-GCM plaintext consists of the ESP Payload. These > differences are illustrated in Figure 4. This figure shows the case > in which the Extended Sequence Number option is not used. When that > option is exercised, the Sequence Number field in the figure would be > replaced with the Extended Sequence Number. >=20 > Importantly, ENCR_NULL_AUTH_AES_GMAC is *not* equivalent to AES-GCM- > ESP with encryption "turned off". However, the ICV computations > performed in both cases are similar because of the structure of the > GHASH function [GCM]. > ... > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nico@cryptonector.com Sun Apr 10 20:07:20 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BAA13A6A49 for ; Sun, 10 Apr 2011 20:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb39kO3l-d4l for ; Sun, 10 Apr 2011 20:07:19 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (jankymail-mx1.g.dreamhost.com [208.97.132.126]) by core3.amsl.com (Postfix) with ESMTP id 85D753A6A43 for ; Sun, 10 Apr 2011 20:07:19 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 71FCF7E405D for ; Sun, 10 Apr 2011 20:07:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=r0OAENAAznne1OVYB/DSI i9g5g4mmsJlFRVnohfGDhdjFlb+hztpgokMiD362VAEgky6v1VVB8dML7ivwSAvy PE5gdkJqudbpRtORXZREBaSLTxXOKkmBIu8IEOwsPCoE+DKN1zf9EjOTs9938Kdj blziNgiBGMuKUDF5a9QCmE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=86ze3Nu3l3wSijHd9FQ/ x40SGRA=; b=nMf0IHpGVLJw+m+PTpc6xubyh69lpFMTKicRqklin5Vb7tUIEjYZ F5YO3KYQq8XRz2b/7SRkbKGOAPVWu4KYs+VPYgLPJVgm7bEN+Xle3qAecXJFpkNy aPbdeVRpH7RETNV11lCuQFrBe+fjZE2qmxSi9xwuIuvw8SBA0bHuyws= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 507357E4058 for ; Sun, 10 Apr 2011 20:07:19 -0700 (PDT) Received: by vws12 with SMTP id 12so4767443vws.31 for ; Sun, 10 Apr 2011 20:07:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.69.240 with SMTP id h16mr6729727vdu.214.1302491238595; Sun, 10 Apr 2011 20:07:18 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Sun, 10 Apr 2011 20:07:18 -0700 (PDT) In-Reply-To: <00fc01cbf48f$d246ff40$76d4fdc0$@com> References: <00fc01cbf48f$d246ff40$76d4fdc0$@com> Date: Sun, 10 Apr 2011 22:07:18 -0500 Message-ID: From: Nico Williams To: Tina Tsou Content-Type: text/plain; charset=UTF-8 Cc: ipsec@ietf.org, frank.bailey@securecommconsulting.com Subject: Re: [IPsec] RFC 5996: IKEv2 - rekey question about 'equivalent' SA's X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 03:07:20 -0000 On Wed, Apr 6, 2011 at 2:21 PM, Tina Tsou wrote: > I thought about rekeying problem when the software lifetime expires. If two > security gateway to initiate rekeying, what is the additional benefit > brought to IKE? I'm not sure what you mean. From kivinen@iki.fi Mon Apr 11 06:01:49 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6132D28C119 for ; Mon, 11 Apr 2011 06:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNc-f3L88okk for ; Mon, 11 Apr 2011 06:01:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E1E1328C0F6 for ; Mon, 11 Apr 2011 06:01:47 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p3BD1dqH029360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Apr 2011 16:01:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p3BD1bCP010346; Mon, 11 Apr 2011 16:01:37 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19874.64433.646496.372226@fireball.kivinen.iki.fi> Date: Mon, 11 Apr 2011 16:01:37 +0300 From: Tero Kivinen To: In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5EF280B@MX14A.corp.emc.com> References: <716209EC190CA740BA799AC4ACCBFB5D1851CEE70A@IXCAEXCH07.ixiacom.com> <19868.21021.903247.236756@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E03E5EF280B@MX14A.corp.emc.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 20 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Queries relating to ESP/AH GCM & GMAC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 13:01:49 -0000 david.black@emc.com writes: > It's more than a decision to not include that capability - IKEv1 exchanges > cannot be protected with combined mode algorithms without significant > incompatible change to IKEv1, as explained in Section 1 of RFC 5282: That is clear, I do not think anybody even dreams using combined mode ciphers on IKEv1. > OTOH, RFC 4106 (GCM), RFC 4309 (CCM), and RFC 4543 (GMAC) were written in > a fashion that allowed their use with ESP (RFC 2406) to be negotiated by > IKEv1 (and also for AH in the case of GMAC). The problem is that combined mode ciphers are not possible to be used with RFC2406, as that does not support combined mode ciphers. To support combined mode ciphers RFC4303 is needed. Also RFC4309 and RFC4543 do already refer to the RFC4303 and RFC4302 for ESP and AH, so they seem to already require ESPv3. > I would strongly object to removal of the IANA registry entries that > support this usage, although I agree that everyone should be using > IKEv2 in preference to IKEv1. I am very worried when people start implementing those ciphers to IKEv1, as there is no way to know which features of the RFC4303 they decide to include too. I agree that completely removing them is not the way we want to go forward, but I would want to strongly recommend people not to add implementation for them when using IKEv1, and based on the text in the RFC6071 I think working group agreed on that too. I would like that recommendation to be reflected also in the IANA page, so implementors who just pick numbers from there would get warning that implementing those ciphers might not lead as good interoperability as they would expect compared when using IKEv2. You have to remember that quite of lot of implementors will simply go to the IANA page, pick the algorithms from there, quickly check out the RFCs listed there and then implement the algorithms. Many of them do not start looking other RFCs related to the problems, and quite many of them have never heard about RFC errata etc... -- kivinen@iki.fi From david.black@emc.com Mon Apr 11 07:09:42 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA96128C0D9 for ; Mon, 11 Apr 2011 07:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZcl6VmyhEAi for ; Mon, 11 Apr 2011 07:09:42 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id DD43428B23E for ; Mon, 11 Apr 2011 07:09:41 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3BE9eIc000316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Apr 2011 10:09:40 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 11 Apr 2011 10:09:34 -0400 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.221.56.108]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3BE8iWi005448; Mon, 11 Apr 2011 10:08:49 -0400 Received: from mx14a.corp.emc.com ([169.254.1.209]) by mxhub22.corp.emc.com ([128.221.56.108]) with mapi; Mon, 11 Apr 2011 10:08:44 -0400 From: To: Date: Mon, 11 Apr 2011 10:08:42 -0400 Thread-Topic: [IPsec] Queries relating to ESP/AH GCM & GMAC Thread-Index: Acv4ScCcvE9somXXQ9mbUJyqNq6CfwABFTIQ Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E041721D28A@MX14A.corp.emc.com> References: <716209EC190CA740BA799AC4ACCBFB5D1851CEE70A@IXCAEXCH07.ixiacom.com> <19868.21021.903247.236756@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E03E5EF280B@MX14A.corp.emc.com> <19874.64433.646496.372226@fireball.kivinen.iki.fi> In-Reply-To: <19874.64433.646496.372226@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: ipsec@ietf.org Subject: Re: [IPsec] Queries relating to ESP/AH GCM & GMAC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 14:09:42 -0000 Hi Tero, I think we're in violent agreement on: > I am very worried when people start implementing those ciphers to > IKEv1, as there is no way to know which features of the RFC4303 they > decide to include too. I agree that completely removing them is not > the way we want to go forward, but I would want to strongly recommend > people not to add implementation for them when using IKEv1, and based > on the text in the RFC6071 I think working group agreed on that too. OTOH, I believe that combined-mode ciphers work fine with RFC 2406, provide= d that some care is taken in the SA negotiation - the combined mode cipher is negotiated as the encryption transform without an additional authentication transform, and the combined mode cipher generates the ESP authentication da= ta. At least RFC 4106 (GCM) is clear on how to do this. > Also RFC4309 and RFC4543 do already refer to the RFC4303 and RFC4302 > for ESP and AH, so they seem to already require ESPv3. Not exactly - like RFC 4106 (GCM), RFC 4309 (CCM) is also written in a fashion that works with both versions of ESP (same encapsulation as RFC 4106, but the text doesn't contain as much explanation of the details). OTOH, use of RFC 4543 (GMAC) with IKEv1 is peculiar, as that results in an authentication transform masquerading as an IKEv1 encryption transform, although RFC 4543 does cite RFC 2409 (IKEv1) as usable for keying. Nonetheless, the following is ok with me: > I would like that recommendation to be reflected also in the IANA > page, so implementors who just pick numbers from there would get > warning that implementing those ciphers might not lead as good > interoperability as they would expect compared when using IKEv2. You > have to remember that quite of lot of implementors will simply go to > the IANA page, pick the algorithms from there, quickly check out the > RFCs listed there and then implement the algorithms. Many of them do > not start looking other RFCs related to the problems, and quite many > of them have never heard about RFC errata etc... My objection was to the suggestion that the IANA registry entries be removed - I have no problem discouraging use of IKEv1 in favor of IKEv2 here and in general. Thanks, --David > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Monday, April 11, 2011 9:02 AM > To: Black, David > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Queries relating to ESP/AH GCM & GMAC >=20 > david.black@emc.com writes: > > It's more than a decision to not include that capability - IKEv1 exchan= ges > > cannot be protected with combined mode algorithms without significant > > incompatible change to IKEv1, as explained in Section 1 of RFC 5282: >=20 > That is clear, I do not think anybody even dreams using combined mode > ciphers on IKEv1. >=20 > > OTOH, RFC 4106 (GCM), RFC 4309 (CCM), and RFC 4543 (GMAC) were written = in > > a fashion that allowed their use with ESP (RFC 2406) to be negotiated b= y > > IKEv1 (and also for AH in the case of GMAC). >=20 > The problem is that combined mode ciphers are not possible to be used > with RFC2406, as that does not support combined mode ciphers. To > support combined mode ciphers RFC4303 is needed. >=20 > Also RFC4309 and RFC4543 do already refer to the RFC4303 and RFC4302 > for ESP and AH, so they seem to already require ESPv3. >=20 > > I would strongly object to removal of the IANA registry entries that > > support this usage, although I agree that everyone should be using > > IKEv2 in preference to IKEv1. >=20 > I am very worried when people start implementing those ciphers to > IKEv1, as there is no way to know which features of the RFC4303 they > decide to include too. I agree that completely removing them is not > the way we want to go forward, but I would want to strongly recommend > people not to add implementation for them when using IKEv1, and based > on the text in the RFC6071 I think working group agreed on that too. >=20 > I would like that recommendation to be reflected also in the IANA > page, so implementors who just pick numbers from there would get > warning that implementing those ciphers might not lead as good > interoperability as they would expect compared when using IKEv2. You > have to remember that quite of lot of implementors will simply go to > the IANA page, pick the algorithms from there, quickly check out the > RFCs listed there and then implement the algorithms. Many of them do > not start looking other RFCs related to the problems, and quite many > of them have never heard about RFC errata etc... > -- > kivinen@iki.fi From balaji.1manarmy@gmail.com Tue Apr 12 00:05:58 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 369BFE076E for ; Tue, 12 Apr 2011 00:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3H6n1G86M-cR for ; Tue, 12 Apr 2011 00:05:57 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfc.amsl.com (Postfix) with ESMTP id EA702E075D for ; Tue, 12 Apr 2011 00:05:56 -0700 (PDT) Received: by qwc23 with SMTP id 23so4519847qwc.31 for ; Tue, 12 Apr 2011 00:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+qJMURyQvVYV6JfWQjITMZfd97QLX3oCIKGZvTOIXhQ=; b=N1knyowbiOYKX6fWhenV+d75kg0HnZcRp3hOf0JAK66YfEG9w8ERny4du4Dh8l/eRy n7UrABzxFgC+VKzC0OuY2TTOQ0svQw69sWjoLKRIOMFjpNv/4F678fnxtUthilN0zYQc JNwk+pC66YE1255GOD1a9m4tsrB6WnJFp6hj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UuPmkZb3jx4z/Kli2it5FjEjqIuvHzgQQSKCGGWIpwmgzFFt2WOYhmMEMOxan91rsf VOZl0xwTbZ5ToCfUl4olgBkEe3wE3zdRrhlofIPlBtPtRo71Soc5ujE2VgU39qjaA/4Z BFFIWEu5aGmtMTkRCVCBXdEXmwh7JjxobuPxI= MIME-Version: 1.0 Received: by 10.229.106.34 with SMTP id v34mr4927589qco.111.1302591956621; Tue, 12 Apr 2011 00:05:56 -0700 (PDT) Received: by 10.229.80.8 with HTTP; Tue, 12 Apr 2011 00:05:56 -0700 (PDT) In-Reply-To: <19868.22183.35956.708462@fireball.kivinen.iki.fi> References: <19868.22183.35956.708462@fireball.kivinen.iki.fi> Date: Tue, 12 Apr 2011 12:35:56 +0530 Message-ID: From: Balaji J To: Tero Kivinen Content-Type: multipart/alternative; boundary=00235429d1d8dc986c04a0b35211 Cc: ipsec@ietf.org Subject: Re: [IPsec] clarification needed in address assignment using IKEv2 Configuration Payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 07:05:58 -0000 --00235429d1d8dc986c04a0b35211 Content-Type: text/plain; charset=ISO-8859-1 Thanks Tero. Can i know why is the DHCP allocated IP scenario not considered in IKEv2 RFC or any separate RFC(like RFC3456 for IKEv1)? Is it only because of CONFIG_PAYLOAD is capable of providing IP to IRAC during IKEv2 negotiation itself. What happens when some corporate network providing vpn service to its employees want to allocate IP to their IRAC ipsec clients through their DHCP server rather than through IKEv2 configuration payload. Is it not a use-case or is this scenario is not expected or was there any draft version also addressing this scenario for ikev2? Regards, ...Balaji.J On Wed, Apr 6, 2011 at 5:33 PM, Tero Kivinen wrote: > Balaji J writes: > > Recently i have started reading the IKEv2 RFC(5996). > > I need a clarification on assigning the ip address using ikev2 protocol > as > > below which i couldn't find in the RFC4718: > > Note that RFC5996 is more resent than RFC4718 and RFC5996 obsoletes > both RFC4306 and RFC4718, so not all RFC4718 text is correct anymore. > We did include most of the things from the RFC4718 to the RFC5996. > > > Is it valid to assign 0.0.0.0 IP address in the CFG_REPLY paylaod in > > IKE_AUTH message to the initiator? > > I do not think there is anything that would explictly prohibit it, but > I would expect most implementations would then try to configure that > ip-address to be used, and that will cause problems. It would be > better not to do that if you want interoperate with other > implementations. > > > I need this information for the scenario where the initiator can obtain > the > > IP address by some other means(say DHCP). > > But still if the initiator needs a secure channel to communicate with the > > gateway first, before sending the DHCP request for obtaining IP address. > > I would say then it would be better to not to return any IP-address to > the client. See section 3.15.4 of RFC5996 for more information. > > One of the ways to fail address assignment failures is to return with > CFG_REPLY but without INTERNAL_IP*_ADDRESS. > > > Now when the DHCP server provides the IP-address to the initiator, > > can the SPD be updated updated at that time(by extracting the ip assigned > to > > the initator from the DHCP message) rather than > > doing the same during the IKE_AUTH response?(as i am thinking of > assigning > > 0.0.0.0 ip during initial IKE_AUTH response in CFG payload) > > That is local implementation matter. If you are assuming IP-address > allocation is done in the DHCP over the IPsec tunnel, and your gateway > does DHCP-packet snoopping on the link, it can modify the SPD based on > that snooping. > > What you are doing sounds a bit like what RFC3456 did for IKEv1. > > > Because when i looked in to RFC4306 under section 2.19(Requesting an > > Internal Address on a Remote Network) , it says, > > "Message from responder to initiator: > > CP(CFG_REPLY)= INTERNAL_ADDRESS(192.0.2.202) > > > > INTERNAL_NETMASK(255.255.255.0) > > INTERNAL_SUBNET( > > 192.0.2.0/255.255.255.0) > > TSi = (0, > > 0-65535,192.0.2.202-192.0.2.202) > > TSr = (0, > > 0-65535,192.0.2.0-192.0.2.255) > > * All returned values will be implementation dependent." > > > > There is no mention in RFC something like "assigning 0.0.0.0 should be > > handled as ERROR". > > So can i safely say assigning 0.0.0.0 ip address is compliant with RFC? > > I would say yes, but do not expect it to work on generic > implementations... > > > Also section 3.15.4. (Address Assignment Failures) says, > > "If the initiator does not receive the IP address(es) required by its > > policy, it MAY keep the IKE SA up and retry the Configuration payload > > as separate INFORMATIONAL exchange after suitable timeout" > > > > Does it mean that the IPSEC-SA cannot be created unless a valid ip is > > assigned? > > It depends. To send some packets over IPsec you need valid IP address. > It is possible that some implementations will happily configure > 0.0.0.0 as their IP-address and use that. On the other hand some > implementations might simply do something different. > > > It is possible to create IPSEC-SA with the traffic-selector alone, rite? > why > > do we need to bother about IP allocation? > > Yes. That is possible. You do not need to allocate IP-addresses using > configuration mode at all during the IKE_AUTH. That is optional > feature of the IKEv2. > > > Assume that there is policy in initiator which says "0.0.0.0 MUST be > > the ip-address allocated by NAS", then is it valid to send the same > > in CFG_REPLY payload? > > If the initiator assumes that kind of setup, it is easier simply just > skip Configuration payloads completely, and just create wildcard IPsec > SA and use that for doing the DHCP. > -- > kivinen@iki.fi > --00235429d1d8dc986c04a0b35211 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Tero.

Can i know why is the DHCP allocated IP scenario not co= nsidered in IKEv2 RFC or any separate RFC(like RFC3456 for IKEv1)?
Is it= only because of CONFIG_PAYLOAD is capable of providing IP to IRAC during I= KEv2 negotiation itself.

What happens when some corporate network providing vpn service to its e= mployees want to allocate IP to their IRAC ipsec clients through their DHCP= server
rather than through IKEv2 configuration payload. Is it not a use= -case or is this scenario is not expected or was there any draft version al= so addressing this scenario for ikev2?

Regards,
...Balaji.J


On Wed, Apr 6, 2011 at 5:33 PM, Tero= Kivinen <kivinen@ik= i.fi> wrote:
Balaji J writes:
> Recently i have started reading the IKEv2 RFC(5996).
> I need a clarification on assigning the ip address using ikev2 protoco= l as
> below which i couldn't find in the RFC4718:

Note that RFC5996 is more resent than RFC4718 and RFC5996 obsoletes both RFC4306 and RFC4718, so not all RFC4718 text is correct anymore.
We did include most of the things from the RFC4718 to the RFC5996.

> Is it valid to assign 0.0.0.0 IP address in the CFG_REPLY paylaod in > IKE_AUTH message to the initiator?

I do not think there is anything that would explictly prohibit it, bu= t
I would expect most implementations would then try to configure that
ip-address to be used, and that will cause problems. It would be
better not to do that if you want interoperate with other
implementations.

> I need this information for the scenario where the initiator can obtai= n the
> IP address by some other means(say DHCP).
> But still if the initiator needs a secure channel to communicate with = the
> gateway first, before sending the DHCP request for obtaining IP addres= s.

I would say then it would be better to not to return any IP-address t= o
the client. See section 3.15.4 of RFC5996 for more information.

One of the ways to fail address assignment failures is to return with
CFG_REPLY but without INTERNAL_IP*_ADDRESS.

> Now when the DHCP server provides the IP-address to the initiator,
> can the SPD be updated updated at that time(by extracting the ip assig= ned to
> the initator from the DHCP message) rather than
> doing the same during the IKE_AUTH response?(as i am thinking of assig= ning
> 0.0.0.0 ip during initial IKE_AUTH response in CFG payload)

That is local implementation matter. If you are assuming IP-address allocation is done in the DHCP over the IPsec tunnel, and your gateway
does DHCP-packet snoopping on the link, it can modify the SPD based on
that snooping.

What you are doing sounds a bit like what RFC3456 did for IKEv1.

> Because when i looked in to RFC4306 under section 2.19(Requesting an > Internal Address on a Remote Network) , it says,
> "Message from responder to initiator:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CP(CFG_REPLY)=3D INTERNAL_ADDRE= SS(192.0.2.202)
>
> INTERNAL_NETMASK(255.255.255.0)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNAL_SUBNET(
> 192.0.2.0= /255.255.255.0)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 TSi =3D (0,
> 0-65535,192.0.2.202-192.0.2.202)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 TSr =3D (0,
> 0-65535,192.0.2.0-192.0.2.255)
> =A0* All returned values will be implementation dependent."
>
> There is no mention in RFC something like "assigning 0.0.0.0 shou= ld be
> handled as ERROR".
> So can i safely say assigning 0.0.0.0 ip address is compliant with RFC= ?

I would say yes, but do not expect it to work on generic
implementations...

> Also section 3.15.4. (Address Assignment Failures) says,
> "If the initiator does not receive the IP address(es) required by= its
> =A0policy, it MAY keep the IKE SA up and retry the Configuration paylo= ad
> =A0as separate INFORMATIONAL exchange after suitable timeout"
>
> Does it mean that the IPSEC-SA cannot be created unless a valid ip is<= br> > assigned?

It depends. To send some packets over IPsec you need valid IP address= .
It is possible that some implementations will happily configure
0.0.0.0 as their IP-address and use that. On the other hand some
implementations might simply do something different.

> It is possible to create IPSEC-SA with the traffic-selector alone, rit= e? why
> do we need to bother about IP allocation?

Yes. That is possible. You do not need to allocate IP-addresses using=
configuration mode at all during the IKE_AUTH. That is optional
feature of the IKEv2.

> Assume that there is policy in initiator which says "0.0.0.0 MUST= be
> the ip-address allocated by NAS", then is it valid to send the sa= me
> in CFG_REPLY payload?

If the initiator assumes that kind of setup, it is easier simply just=
skip Configuration payloads completely, and just create wildcard IPsec
SA and use that for doing the DHCP.
--
kivinen@iki.fi

--00235429d1d8dc986c04a0b35211-- From kivinen@iki.fi Tue Apr 12 04:54:23 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0C2A7E0705 for ; Tue, 12 Apr 2011 04:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmUrNwL+YMd8 for ; Tue, 12 Apr 2011 04:54:21 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfc.amsl.com (Postfix) with ESMTP id A6EEDE066B for ; Tue, 12 Apr 2011 04:54:18 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p3CBsBcQ017436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2011 14:54:11 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p3CBsBJI014016; Tue, 12 Apr 2011 14:54:11 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19876.15715.162454.493049@fireball.kivinen.iki.fi> Date: Tue, 12 Apr 2011 14:54:11 +0300 From: Tero Kivinen To: Balaji J In-Reply-To: References: <19868.22183.35956.708462@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 18 min Cc: ipsec@ietf.org Subject: Re: [IPsec] clarification needed in address assignment using IKEv2 Configuration Payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 11:54:23 -0000 Balaji J writes: > Can i know why is the DHCP allocated IP scenario not considered in > IKEv2 RFC or any separate RFC(like RFC3456 for IKEv1)? It was considered, but working group decided that it is too complicated and decided to include built in support for address allocation using configuration payloads. During the discussion in 2003 we had 2 major proposals, either using DHCP over IKE or using configuration payloads. The DHCP inside the IPsec tunnel was already mostly ruled out as it was only done in first place because ipsec working group was forbidden to modify ike, so that was only option. If you are interested in the history and reasons why we did select configuration payload you can see the discussion in the ipsec list around year 2003. This thread seems to be the deciding one: http://www.vpnc.org/ietf-ipsec/03.ipsec/msg00954.html > Is it only because of CONFIG_PAYLOAD is capable of providing IP to IRAC > during IKEv2 negotiation itself. Yes. None of the implementors really liked the way to use dhcp over IPsec tunnel to get configuration. That was only made because we could not change IKE. There are very few implementions who ever supported that RFC3456. > What happens when some corporate network providing vpn service to > its employees want to allocate IP to their IRAC ipsec clients > through their DHCP server rather than through IKEv2 configuration > payload. They will either implement some kind of dhcp proxy system where the VPN gateway will act as dhcp client and get addresses from the dhcp server and then give them out in the configuration payloads, or they simply use separate pool of addresses for the remote access users and give them out directly from the vpn gateway. This last method is much more common, as it also solves the routing problems, i.e. that address pool can be such address set that they are always routed to the vpn gateway, without any need of proxy arping or similar. > Is it not a use-case or is this scenario is not expected or was > there any draft version also addressing this scenario for ikev2? In normal case it is assumed that corporates will use separate pools of address for local users and for remote access users, and the local addresses are given out from dhcp server and remote access addresses are given out using configuration payload. If needed the remote access addresses can also be fetched from the radius server, i.e. when the user authenticates himself using EAP or similar the radius server also returns the address to be given to that user. -- kivinen@iki.fi From kivinen@iki.fi Tue Apr 12 05:18:21 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DEFCEE07BA for ; Tue, 12 Apr 2011 05:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gM9JyEjTYTN for ; Tue, 12 Apr 2011 05:18:21 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfc.amsl.com (Postfix) with ESMTP id 13C96E0699 for ; Tue, 12 Apr 2011 05:18:19 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p3CCHnmr019547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2011 15:17:49 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p3CCHkF2015176; Tue, 12 Apr 2011 15:17:46 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19876.17130.712471.646073@fireball.kivinen.iki.fi> Date: Tue, 12 Apr 2011 15:17:46 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 22 min X-Total-Time: 22 min Cc: dennis.kuegler@bsi.bund.de, dharkins@arubanetworks.com, seonghan.shin@aist.go.jp, sfluhrer@cisco.com Subject: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 12:18:22 -0000 As we all know we (as a wg) did fail to pick one secure password authentication method, and the latest count seems to be that we are going to have 4 of them. All of them seem to be mostly same from the IKEv2 protocol point of view, but each of them are implemented differently. All of the proposals do have very common structure, i.e. they add some new payloads and round trips to the IKE_AUTH step and in the end when the secure password exchange finishes they will send (differently created) auth payloads and finish the negotiation. When looking at the protocols it seems to me that we could create one generic framework for all of the methods, i.e. we could make it so that all of the methods can co-exists in the same implementation and they can be configured to be used just like any other feature. I do not see any point of allocating separate payload numbers, exchange types, error codes etc for each of them, as that will add much more complexity to the implementations. What I propose it that we create one secure password authentication method framework (SPAM framework) and all those drafts (spsk, hush, augmented pake, pace) will be changed to use that same framework. I can write that framework draft if needed. The framework would be something like this: 1) Add new notification to the IKE_SA_INIT telling which SPAM algorithms are supported. This will notification will include tuple of 8-bit integers containing the 8-bit SPAM algorith number and 8-bit password preprosessing technique number. The initiator sends all supported algorithms and responder will pick one algorithm which is to be used. The other option here is that reponder lists which algorithms which it supports and initiator can then use any of them. Payload format will be: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol ID | SPI Size | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Security Parameter Index (SPI) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Notification Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where Protocol ID will be 0, SPI Size 0, Notify Message Type TBD, SPI empty, and Notification data contains those numbers. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPAM Alg 1 | Prep Method 1 | SPAM Alg 2 | Prep Method 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPAM Alg 3 | Prep Method 3 | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SPAM Algs would be something like SPSK, Pace, AugPake, hush etc. Prep methods would be something like none, rfc2759, SASLprep etc. 2) Add new payload to the IKEv2 which will contain all SPAM specific payloads. This payload will have following format: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPAM Alg | Prep Method | SPAM Alg Specific Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ SPAM Algorithm Specific Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the SPAM Algorithm and Prep method are the selected ones from the IKE_SA_INIT, and the SPAM Algorithm Specific Type is the payload type specific for each SPAM Algorithm. For SPSK the SPAM Alg Specific Types is commit. For pace the SPAM Alg Specific Types are ENONCE, PKEi, PKEr. For AugPake the SPAM Alg Specific Types are PVi, PVr, Vrfyi, Vrfyr. For hush the SPAM Alg Specific Types are Encrypt, and Protect. The SPAM Algorithm Specific Data contains then data specific to the algorithm and the type. 3) The IKE_SA_INIT and IKE_AUTH are used as exchange types, but the extra payloads in them depend on the SPAM algorithm used, and the SPAM algorithm used also affects the AUTH payload generation. The exchange will similar to EAP, i.e.: Initiator Responder ------------------------------------------------------------------- HDR, SAi1, KEi, Ni, N(SPAM_METHODS) --> <-- HDR, SAr1, KEr, Nr, [CERTREQ], N(SPAM_METHODS) HDR, SK {IDi, [CERTREQ,] SPAM_PAYLOAD, SPAM_PAYLOAD, ... [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] SPAM_PAYLOAD, SPAM_PAYLOAD, ... } HDR, SK {SPAM_PAYLOAD, ...} --> <-- HDR, SK {SPAM_PAYLOAD, ...} HDR, SK {[SPAM_PAYLOAD, ...], AUTH} --> <-- HDR, SK {[SPAM_PAYLOAD, ...], AUTH, SAr2, TSi, TSr } I.e. there can be multiple IKE_AUTH exchanges, each having number of SPAM_PAYLOADs in them (from 0 to n, where n depends on the SPAM algorithm selected). The first IKE_AUTH request contains normal IDi, IDr, SAi2, TSi, TSr. The final IKE_AUTH request contains AUTH payload which includes normal data included in AUTH, and the algorithm specific data. The final IKE_AUTH response contains similar AUTH and SAr2, TSi, and TSr payloads. Final messages may also contain extra SPAM_PAYLOADs if needed. This kind of framework would allow using any of the secure password authentication methods in a way where they can co-exist in the same implementation. If the implementation is done properly, then it might be even possible to make it so that new algorithms can be added easily. The proposed protocol is mostly there for start of discussion and the final version might be different what I outlined above. I have quickly checked all password method drafts through and I think it should be quite easy to fit all of the mehods to this kind of framework. If people think this is good idea, I can write the first version of the framework draft and submit it as internet-draft quite soon, but before I start working on this I would like to get some feedback from others whether this is good idea, and whether authors of those methods would be willing to convert their drafts to use this framework. If the authors are not willing to use this framework then there is no point of creating the framework. -- kivinen@iki.fi From ynir@checkpoint.com Tue Apr 12 06:30:25 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A12E5E07AE for ; Tue, 12 Apr 2011 06:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.388 X-Spam-Level: X-Spam-Status: No, score=-7.388 tagged_above=-999 required=5 tests=[AWL=3.211, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s29pG6yMZeTN for ; Tue, 12 Apr 2011 06:30:24 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfc.amsl.com (Postfix) with ESMTP id 040E5E07AA for ; Tue, 12 Apr 2011 06:30:21 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p3CDT6ID018295; Tue, 12 Apr 2011 16:29:20 +0300 X-CheckPoint: {4DA46155-0-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 12 Apr 2011 16:29:05 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 12 Apr 2011 15:29:05 +0200 From: Yoav Nir To: Tero Kivinen Date: Tue, 12 Apr 2011 15:29:05 +0200 Thread-Topic: [IPsec] Proposal for the secure password authentication method problem Thread-Index: Acv5FZhfwz40E+OmQgqY2b/eI7NnYw== Message-ID: References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> In-Reply-To: <19876.17130.712471.646073@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "dennis.kuegler@bsi.bund.de" , "dharkins@arubanetworks.com" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 13:30:25 -0000 On Apr 12, 2011, at 3:17 PM, Tero Kivinen wrote: > This kind of framework would allow using any of the secure password > authentication methods in a way where they can co-exist in the same > implementation. If the implementation is done properly, then it might > be even possible to make it so that new algorithms can be added > easily. >=20 > The proposed protocol is mostly there for start of discussion and the > final version might be different what I outlined above. I have quickly > checked all password method drafts through and I think it should be > quite easy to fit all of the mehods to this kind of framework. >=20 > If people think this is good idea, I can write the first version of > the framework draft and submit it as internet-draft quite soon, but > before I start working on this I would like to get some feedback from > others whether this is good idea, and whether authors of those methods > would be willing to convert their drafts to use this framework. If the > authors are not willing to use this framework then there is no point > of creating the framework.=20 Hi Tero I have mixed feelings about this. It's better than all four of those drafts= advancing separately. OTOH this plug-innable architecture is pretty much a= dmitting defeat. It sets us up to have a situation like EAP, with lots of d= ifferent methods, and no guide to implementers as to which methods to imple= ment. But I guess it's the lesser evil. Yoav From nico@cryptonector.com Tue Apr 12 07:38:12 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 74F4FE079E for ; Tue, 12 Apr 2011 07:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8Lxg3wTSeLd for ; Tue, 12 Apr 2011 07:38:11 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfc.amsl.com (Postfix) with ESMTP id 6DEA5E0798 for ; Tue, 12 Apr 2011 07:38:11 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 1640C2C8075 for ; Tue, 12 Apr 2011 07:38:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=lM8gPiV9RZKDfFBz7hCAwOPcGKCW0nKoM/6aR7iPdjyl Arsd0ZzSkJ9NdvhCGN5flC5McIr9+N1rFwWG9qy4VC6m4ZpZ0bGVtu+pb5ELfC6s 3tSwBKPSKXxcT2KCZZTFEl3ArAwhbv+63QM4olb9cq+4/vRpL+QErQTnqyK90oM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=bDncwm8cmgpABRoYi1HhoG/5d1o=; b=FL4oO+UmG/E uqSFT5y1h0qR8S3IRKWY+xJohDfg4vVz3D+OQLymxjztsVqeIx/Z67ZjahuUOv33 /v3BuN2sLfTNBXb5p9OfQHVuSZWTbNCNneVEUPgun4aouc2CEkrWsxQ7Ll37NqNk PFrYMAmR6kqiZq7OlDu1rEiUJxvrgJS4= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id D39CF2C806E for ; Tue, 12 Apr 2011 07:38:09 -0700 (PDT) Received: by vws12 with SMTP id 12so6357131vws.31 for ; Tue, 12 Apr 2011 07:38:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.188.230 with SMTP id gd6mr4113967vdc.294.1302619089109; Tue, 12 Apr 2011 07:38:09 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Tue, 12 Apr 2011 07:38:09 -0700 (PDT) In-Reply-To: References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> Date: Tue, 12 Apr 2011 09:38:09 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dharkins@arubanetworks.com" , Tero Kivinen , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 14:38:12 -0000 On Tue, Apr 12, 2011 at 8:29 AM, Yoav Nir wrote: > I have mixed feelings about this. It's better than all four of those draf= ts advancing separately. OTOH this plug-innable architecture is pretty much= admitting defeat. It sets us up to have a situation like EAP, with lots of= different methods, and no guide to implementers as to which methods to imp= lement. Plugin architecture !=3D no guidance as to required to implement mechanisms/methods. Besides, one of the nice things about plugin architectures is that third parties can fill in voids when specific methods/mechanisms go unimplemented. > But I guess it's the lesser evil. I don't get the hostility to pluggable authentication architectures. Why on Earth should any of us dictate to users what kinds of authentication infrastructures they must have? For far too long we've had too many protocols with completely disjoint authentication technology support, leading to customers having to deploy many authentication infrastructures. Some protocols only handle PKIX well. Others only handle Kerberos well. Others only handle AAA well. Yet others have ad-hoc authentication systems. Forcing customers to deploy multiple authentication infrastructures means forcing them to setup expensive synchronization for expensive systems that they shouldn't need. How is that a good thing? The *only* way to put a stop to this madness is to make all these protocols pluggable. Some of us have been trying to do so for a while. We have the following successes to point to: - SASL/GS2 -- a new bridge for using GSS-API mechanisms in SASL applicatio= ns. - SSHv2 support for GSS-API-based authentication. - Channel binding (RFCs 5056 and 5929), which allows for composition of security technologies. - IKEv2 and KINK (which altogether allow IPsec to support the use of PKIX, Kerberos and EAP for end-point authentication). - ABFAB WG -- a WG working on standardizing an EAP-based, federation-capable GSS-API mechanism. I count this as a success because ABFAB is quite far along. Other work items in progress that should help round up this picture: - PKU2U (a PKIX-based GSS-API mechanism). - Additional GSS mechanisms being proposed at ABFAB and/or KITTEN (there's a SAML-based one and an OAuth-based one). - draft-williams-tls-sasl-opt. We have quite a few protocols that support SASL or the GSS-API straight out= : - SASL application protocols: LDAP, IMAP, SMTP/SUBMIT, ... - GSS application protocols: RPCSEC_GSS/NFSv4, DNS (GSS-TSIG), SSHv2, FTP,= ... We also have protocols that only support PKIX well and everything else in a half-hearted way, if at all (TLS, I'm looking at you). Please, let's put an end to the madness and adopt a pluggable approach to authentication (being careful to ensure channel binding to the actual security layers whenever the authentication facility's security layers are not used or when it lacks them). Nico PS: "Security layer" is a term from SASL meaning "the layer that provides integrity and, optionally, confidentiality protection to application data. From nico@cryptonector.com Tue Apr 12 09:34:45 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CE372E07A0 for ; Tue, 12 Apr 2011 09:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOH1Mwo6WgUz for ; Tue, 12 Apr 2011 09:34:45 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfc.amsl.com (Postfix) with ESMTP id 14D33E072E for ; Tue, 12 Apr 2011 09:34:45 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 70936678083 for ; Tue, 12 Apr 2011 09:34:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=jP1k5S8ffrR8GpPskzk+a 2/I2ujnLbpNrQxE5vIhjNMxA6hLCE2PpAZMNQasKIZ9wGMjHTuxcGqZ3iKioYWeU nimDwKUvwNjtnJ+WVXvciTyNLvuaDUGiizPlSPkQRVrd4POKAWQ4BZv4MYWqjUSP 2XdfzlbuVbgjo+WTIGyyxo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=U93pQzT21URH4lD+yQ9E DD9E/vk=; b=R1pxSEbrvBSK4gpi6UOZ12Ilg37zBayqc4dfyM0DxtbfRW4RuCjQ 0og8sWv9BSNGcQZbuHrhVArgZYc+JGyU4sYcksSFWKiCBJpm8uQ5hE/7jgSABFFQ UDkdy44C7Mr2QY9Sj7DCPkiH5jJkGzdgji2gZnRcJBILfK3cbXrXDzk= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 17F9D6780E9 for ; Tue, 12 Apr 2011 09:30:26 -0700 (PDT) Received: by vws12 with SMTP id 12so6474102vws.31 for ; Tue, 12 Apr 2011 09:30:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.130 with SMTP id l2mr4892147vdv.14.1302625823393; Tue, 12 Apr 2011 09:30:23 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Tue, 12 Apr 2011 09:30:23 -0700 (PDT) In-Reply-To: <19876.17130.712471.646073@fireball.kivinen.iki.fi> References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> Date: Tue, 12 Apr 2011 11:30:23 -0500 Message-ID: From: Nico Williams To: Tero Kivinen Content-Type: text/plain; charset=UTF-8 Cc: ipsec@ietf.org, dennis.kuegler@bsi.bund.de, dharkins@arubanetworks.com, seonghan.shin@aist.go.jp, sfluhrer@cisco.com Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 16:34:45 -0000 On Tue, Apr 12, 2011 at 7:17 AM, Tero Kivinen wrote: > As we all know we (as a wg) did fail to pick one secure password > authentication method, and the latest count seems to be that we are > going to have 4 of them. > > All of them seem to be mostly same from the IKEv2 protocol point of > view, but each of them are implemented differently. All of the > proposals do have very common structure, i.e. they add some new > payloads and round trips to the IKE_AUTH step and in the end when the > secure password exchange finishes they will send (differently created) > auth payloads and finish the negotiation. > > When looking at the protocols it seems to me that we could create one > generic framework for all of the methods, i.e. we could make it so > that all of the methods can co-exists in the same implementation and > they can be configured to be used just like any other feature. I do > not see any point of allocating separate payload numbers, exchange > types, error codes etc for each of them, as that will add much more > complexity to the implementations. We already have three generic authentication frameworks: SASL, GSS-API, and EAP. Must we add a fourth one? (We also have a number of less generic ones, such as the ones in SSHv2, TLS, ...). Considering that: a) we have EAP in IKEv2, b) there are reserved numbers for using the GSS-API in IKEv1, and we could make it usable in IKEv2, c) we have a plethora of EAP methods and GSS-API mechanisms available now or soon, ... why create a new framework? Nico -- From nico@cryptonector.com Tue Apr 12 10:00:49 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7E331E0868 for ; Tue, 12 Apr 2011 10:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ucEI9pdM0TD for ; Tue, 12 Apr 2011 10:00:48 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfc.amsl.com (Postfix) with ESMTP id CACAEE0816 for ; Tue, 12 Apr 2011 10:00:48 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id EF621350072 for ; Tue, 12 Apr 2011 10:00:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=NBhUXpNekwckUtuxzLqS7VFyVYUG8z2grHxTb27EwwVu 2l0jGfesEufSxoSX6gDGOXl22pgjo1RTSOzDcbUqxM16s14RuGc3EV1MjZtz7AdL dtBuIodXnvArQQOSo+f5UJ6wzAyD5E62c4t0W6OEIRCcTvANhfoik7t639RlJAM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=inCue1Td87LkxWsTYAlQyTFTaMg=; b=BmtxQQKUUbh W2ekAVvTouy47GeKfijyfAE6wW48/46UpwKKRqljNEz43IltQ/TY/DXrpb+o93ff dH6jR5FvKZmtmRfG18jjL3KoS7pbxYEf4g1Rd7lkOBJeYtkQKOt3fIWt0oYhiYlf vopQ5D44MsG/Uk5b/9z2lunCC4mgDA/Y= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id C211235005B for ; Tue, 12 Apr 2011 10:00:47 -0700 (PDT) Received: by vws12 with SMTP id 12so6502608vws.31 for ; Tue, 12 Apr 2011 10:00:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.225 with SMTP id el1mr4256445vdb.174.1302627647098; Tue, 12 Apr 2011 10:00:47 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Tue, 12 Apr 2011 10:00:47 -0700 (PDT) In-Reply-To: <19876.17130.712471.646073@fireball.kivinen.iki.fi> References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> Date: Tue, 12 Apr 2011 12:00:47 -0500 Message-ID: From: Nico Williams To: Tero Kivinen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, dennis.kuegler@bsi.bund.de, dharkins@arubanetworks.com, seonghan.shin@aist.go.jp, sfluhrer@cisco.com Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 17:00:49 -0000 On Tue, Apr 12, 2011 at 7:17 AM, Tero Kivinen wrote: > 1) Add new notification to the IKE_SA_INIT telling which SPAM > =C2=A0 algorithms are supported. This will notification will include tupl= e > =C2=A0 of 8-bit integers containing the 8-bit SPAM algorith number and > =C2=A0 8-bit password preprosessing technique number. The initiator sends > =C2=A0 all supported algorithms and responder will pick one algorithm > =C2=A0 which is to be used. The other option here is that reponder lists > =C2=A0 which algorithms which it supports and initiator can then use any > =C2=A0 of them. 8-bit?! BTW, sending SASL mechanism names, or EAP method names, or GSS-API mechnism OIDs wouldn't be that different from sending 8-bit mechanism numbers. But it'd be way better, because you'd be using an off-the-shelf framework. Off the shelf is good, for all the reasons I gave earlier and then some (more mechanisms exist, the frameworks have a better chance of being pluggable as implemented, code reuse, specification reuse, ...) > 3) The IKE_SA_INIT and IKE_AUTH are used as exchange types, but the > =C2=A0 extra payloads in them depend on the SPAM algorithm used, and the > =C2=A0 SPAM algorithm used also affects the AUTH payload generation. The > =C2=A0 exchange will similar to EAP, i.e.: AUTH payloads should be where channel binding is done, yes. We should definitely think in terms of CB here, and if you were to use SASL or the GSS-API then you'd get the necessary CB functionality right off the bat. (Incidentally, your design also reminds me of SSHv2.) Nico -- From dharkins@lounge.org Tue Apr 12 11:01:13 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 14D6EE07E9 for ; Tue, 12 Apr 2011 11:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5cKuUHLhlEp for ; Tue, 12 Apr 2011 11:01:10 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfc.amsl.com (Postfix) with ESMTP id 075BAE067F for ; Tue, 12 Apr 2011 11:01:10 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A8AA810224050; Tue, 12 Apr 2011 11:01:08 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 12 Apr 2011 11:01:09 -0700 (PDT) Message-ID: In-Reply-To: References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> Date: Tue, 12 Apr 2011 11:01:09 -0700 (PDT) From: "Dan Harkins" To: "Nico Williams" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Yoav Nir , Tero Kivinen , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 18:01:13 -0000 Hi Nico, On Tue, April 12, 2011 7:38 am, Nico Williams wrote: > I don't get the hostility to pluggable authentication architectures. > Why on Earth should any of us dictate to users what kinds of > authentication infrastructures they must have? We do that when we ship support for some authentication credential in product. Whether it's a particular EAP method or a TLS ciphersuite or support for particular authentication method in IKE. > For far too long we've had too many protocols with completely disjoint > authentication technology support, leading to customers having to > deploy many authentication infrastructures. Some protocols only > handle PKIX well. Others only handle Kerberos well. Others only > handle AAA well. Yet others have ad-hoc authentication systems. > > Forcing customers to deploy multiple authentication infrastructures > means forcing them to setup expensive synchronization for expensive > systems that they shouldn't need. How is that a good thing? That's exactly what this pluggable stuff gets us. GSS, EAP, RADIUS, and how is authentication happening? Well that's not really decided yet. But we have these multiple, pluggable, authentication infrastructures that you have to support before you can even get to the point of thinking of your authentication credential. > The *only* way to put a stop to this madness is to make all these > protocols pluggable. Actually I think that is the madness. If the EAP in TLS plan goes forward we could have some deployment of EAP-TLS with the TLS ciphersuite doing EAP and the EAP method used for that is IKEv2 and using EAP-only as the authentication method and EAP-GSS inside that! > Some of us have been trying to do so for a > while. We have the following successes to point to: > > - SASL/GS2 -- a new bridge for using GSS-API mechanisms in SASL > applications. > - SSHv2 support for GSS-API-based authentication. > - Channel binding (RFCs 5056 and 5929), which allows for composition > of security technologies. > - IKEv2 and KINK (which altogether allow IPsec to support the use of > PKIX, Kerberos and EAP for end-point authentication). > - ABFAB WG -- a WG working on standardizing an EAP-based, > federation-capable GSS-API mechanism. I count this as a success > because ABFAB is quite far along. I think I'm more in the camp of counting ABFAB as an abomination. Treating authentication protocols that have been designed for a particular purpose as some generic mechanism results in much insecurity in the deployed world (the "let's use TLS" instinct is widespread and it is seldom deployed correctly. Making them totally pluggable can only make it worse. regards, Dan. From nico@cryptonector.com Tue Apr 12 11:53:47 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 777BEE0895 for ; Tue, 12 Apr 2011 11:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.784 X-Spam-Level: X-Spam-Status: No, score=-0.784 tagged_above=-999 required=5 tests=[AWL=-1.107, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_AVOID=2.3] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6IIrf9XTdS8 for ; Tue, 12 Apr 2011 11:53:46 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfc.amsl.com (Postfix) with ESMTP id 32411E0716 for ; Tue, 12 Apr 2011 11:53:46 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 3452354077 for ; Tue, 12 Apr 2011 11:53:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=eCHxOLQYeBQ96yWDjuKb7Za4hJ08E/6Q8ToG2TMPMij2 IuCM9tZ+Y7trSKQQD8bgguC7tgpuErHI+N8KmECQzxupcVtNW5I+fYGgd+ho/CHN e+Puiu2wElbUpH5FNl+NIxJagWHVMxQM1+EkQyAoTR4azwMY3cO7mCiyR0FYGhw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=xw6J6V0Ferv0fElRX/yZ7bjVSS8=; b=hTf1v5v1g2f /5RSaxIblu4KltEIB2HXUn5BlfT4S5RXsZo9niqtjtQypWinqq5y7fWIBukKElTq WPyZtvE/2JZtSKN6OPvJ7B6/OBQNflUXSTtyFldJ5Eg8jd4KcP9Jfwx2sGpX/qGB KzWmlE1mtTaddmLb0xvTrqxVFJorIFoY= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id F00DC5406F for ; Tue, 12 Apr 2011 11:53:44 -0700 (PDT) Received: by vxg33 with SMTP id 33so6362176vxg.31 for ; Tue, 12 Apr 2011 11:53:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.225 with SMTP id el1mr4434617vdb.174.1302634424337; Tue, 12 Apr 2011 11:53:44 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Tue, 12 Apr 2011 11:53:44 -0700 (PDT) In-Reply-To: References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> Date: Tue, 12 Apr 2011 13:53:44 -0500 Message-ID: From: Nico Williams To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Yoav Nir , Tero Kivinen , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 18:53:47 -0000 On Tue, Apr 12, 2011 at 1:01 PM, Dan Harkins wrote: > On Tue, April 12, 2011 7:38 am, Nico Williams wrote: >> I don't get the hostility to pluggable authentication architectures. >> Why on Earth should any of us dictate to users what kinds of >> authentication infrastructures they must have? > > =C2=A0We do that when we ship support for some authentication credential > in product. Whether it's a particular EAP method or a TLS ciphersuite > or support for particular authentication method in IKE. Who ships credentials? Customers control credentials, not vendors. (The only exception is default trust anchors, which are a sort of credential.) >> Forcing customers to deploy multiple authentication infrastructures >> means forcing them to setup expensive synchronization for expensive >> systems that they shouldn't need. =C2=A0How is that a good thing? > > =C2=A0That's exactly what this pluggable stuff gets us. GSS, EAP, RADIUS, > and how is authentication happening? Well that's not really decided > yet. But we have these multiple, pluggable, authentication infrastructure= s > that you have to support before you can even get to the point of thinking > of your authentication credential. Pluggable authentication frameworks are NOT the cause of multiplicity of authentication infrastructures. You might have argued that if we'd only ever had one True authentication mechanism then pluggable frameworks would have been bad, but a) you didn't so argue, b) that was never the case anyways (SASL mechanisms came first, the framework later, same for EAP, for example, and Kerberos and PKIX are contemporaries, and so on). Reading into what you write above you seem to think that it's not possible to abstract authentication sufficiently well (for IKEv2's purposes, in this case). I disagree. I'll grant only that there's only one framework that has gone any of the distance to properly abstracting authentication, and that's the GSS-API (which I gather you revile, but preferably you could explain in detail). >> The *only* way to put a stop to this madness is to make all these >> protocols pluggable. > > =C2=A0Actually I think that is the madness. > > =C2=A0If the EAP in TLS plan goes forward we could have some deployment > of EAP-TLS with the TLS ciphersuite doing EAP and the EAP method used > for that is IKEv2 and using EAP-only as the authentication method and > EAP-GSS inside that! I'm not fond of the proliferation of authentication frameworks. If you thought I was, you misunderstood. I'd rather see one framework win (which is why we did the SASL/GS2 bridge to GSS-API mechanisms). We have all the frameworks that we have because historically various groups created them independently, often as a generalization of the reality that various protocols were pluggable but without a generic framework (this is true of EAP and SASL). And here Tero is proposing yet another pluggable framework. Tero's proposal: create a new pluggable authentication framework. My proposal: pick an off-the-shelf framework. Your proposal: ?? Force a single authentication mechanism on all? But you know what will result: eventually others will add alternatives, and then someone will say "hey! I know, we can generalize what we have and create a framework", and then we've repeated history, and badly at that. What am I missing? I mean, I get the sentiment and I sympathize (I wish we had had exactly one pluggable authentication framework, not N>3 as we do), I do. We need stronger arguments either way, however. >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Some of us have been trying to do so for a >> while. =C2=A0We have the following successes to point to: >> >> =C2=A0- SASL/GS2 -- a new bridge for using GSS-API mechanisms in SASL >> applications. >> =C2=A0- SSHv2 support for GSS-API-based authentication. >> =C2=A0- Channel binding (RFCs 5056 and 5929), which allows for compositi= on >> of security technologies. >> =C2=A0- IKEv2 and KINK (which altogether allow IPsec to support the use = of >> PKIX, Kerberos and EAP for end-point authentication). >> =C2=A0- ABFAB WG -- a WG working on standardizing an EAP-based, >> federation-capable GSS-API mechanism. =C2=A0I count this as a success >> because ABFAB is quite far along. > > =C2=A0I think I'm more in the camp of counting ABFAB as an abomination. I'm not really fond of some aspects of it. I strongly dislike certain aspects of EAP, AAA, and SAML -- all major components of ABFAB. But it fills a void. And it will work with the infrastructures that people have. I don't see anyone coming forth with better alternatives. In any case, the ABFAB WG's mechanism fits in an existing framework, so there are only two possible outcomes: it gets adopted or it doesn't. Compare to the possible outcomes if we create new frameworks: likely more fragmentation of authentication mechanism support, leading to more redundant authentication infrastructure deployment or else market failure for the framework and the protocol consuming it. > =C2=A0Treating authentication protocols that have been designed for a > particular purpose as some generic mechanism results in much insecurity > in the deployed world (the "let's use TLS" instinct is widespread and it > is seldom deployed correctly. Making them totally pluggable can only make > it worse. "Results in much insecurity" is a strong assertion and requires something a lot more concrete than pointing at TLS. The fact that TLS is used in weak ways is not really a result of having pluggable authentication systems -- I'd say it's exactly the reverse because the lack of suitable password-based authentication mechanisms meant it was easiest to just send passwords over some secure channel, and that channel could only really be secured with a PKI, all the while PKI could not scale to Internet scale, which meant we ended up with what we have. Whereas if we'd had composeable authentication mechanisms we could have had channel binding to TLS eons ago and saved ourselves a lot of trouble. The fact is that technology grows organically. When you analyze the failures of the past you have to be careful to find the right lessons. Here we see what would be a new branch of organic growth, but in this case we really can and must apply lessons from the past, one of which is that we shouldn't re-invent wheels willy nilly. Nico -- From dharkins@lounge.org Tue Apr 12 12:39:16 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4859CE08E2 for ; Tue, 12 Apr 2011 12:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMzSVzSWXAni for ; Tue, 12 Apr 2011 12:39:15 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfc.amsl.com (Postfix) with ESMTP id 223D9E08E1 for ; Tue, 12 Apr 2011 12:39:15 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 22D061022404C; Tue, 12 Apr 2011 12:39:14 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 12 Apr 2011 12:39:14 -0700 (PDT) Message-ID: <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> In-Reply-To: References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> Date: Tue, 12 Apr 2011 12:39:14 -0700 (PDT) From: "Dan Harkins" To: "Nico Williams" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Yoav Nir , Dan Harkins , Tero Kivinen , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 19:39:16 -0000 Hi Nico, On Tue, April 12, 2011 11:53 am, Nico Williams wrote: > On Tue, Apr 12, 2011 at 1:01 PM, Dan Harkins wrote: >> On Tue, April 12, 2011 7:38 am, Nico Williams wrote: >>> I don't get the hostility to pluggable authentication architectures. >>> Why on Earth should any of us dictate to users what kinds of >>> authentication infrastructures they must have? >> >>  We do that when we ship support for some authentication credential >> in product. Whether it's a particular EAP method or a TLS ciphersuite >> or support for particular authentication method in IKE. > > Who ships credentials? Customers control credentials, not vendors. > (The only exception is default trust anchors, which are a sort of > credential.) I said _support_ some credential, not ship the credential. If your product supports EAP-SIM then what I'm saying is you are "dictating to users what kind of authentication infrastructure they must have", namely one that supports SIM cards. > I'm not fond of the proliferation of authentication frameworks. If > you thought I was, you misunderstood. I'd rather see one framework > win (which is why we did the SASL/GS2 bridge to GSS-API mechanisms). > We have all the frameworks that we have because historically various > groups created them independently, often as a generalization of the > reality that various protocols were pluggable but without a generic > framework (this is true of EAP and SASL). And here Tero is proposing > yet another pluggable framework. > > Tero's proposal: create a new pluggable authentication framework. > My proposal: pick an off-the-shelf framework. > > Your proposal: ?? Force a single authentication mechanism on all? No no, not at all. Robust and misuse resistance is my proposal. Using the best technique directly in the protocol for the chosen credential. If you want to use certificates then use a certificates in the exchange. If you want to use a password then use a password in the exchange. But "lets use X" where X is some pluggable framework is definitely not my proposal. I proposed adding PAKE to IKE because people use passwords for authentication and that is rife with misuse. "Why not just use EAP?" was the question. Why not just use this pluggable authentication method? Well two reasons: 1) it's a pointless encapsulation that also increases the number of rounds; and 2) because it's pluggability encourages misuse (i.e. do EAP-MSCHAPv2 in EAP-only IKE). I'm a bit undecided on Tero's proposal. I tend to get in trouble when I ascribe motivation to things people do so I won't do that, but as someone who actually implements the protocols we design here I think having n protocols, where n > 1, to solve a single problem with no clear "winner" means that for interoperability reasons I have to implement all n and that's a shame. Since Tero actually implements these protocols too I think he might share that concern. It might be possible to get the authors of the competing drafts to rely on a common method of identifying the intent of the initiator (currently PACE uses a Notify and SPSK uses the mandatory bit) and ensure that their protocols all look the same-- send a blob, get a blob, send another blob, get another blob-- and to mix results from PAKE exchange into results of the D-H exchange in a uniform manner and we might get the equivalent of what he's proposing without Yet Another Pluggable Architecture (which I guess we both agree would be not-so-good). Now the drafts are in LC. Maybe a few comments could get the authors to align their drafts so they look architecturally identical while implementing different exchanges. regards, Dan. From nico@cryptonector.com Tue Apr 12 12:45:03 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8EC89E084A for ; Tue, 12 Apr 2011 12:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RlOK7bpzj8U for ; Tue, 12 Apr 2011 12:45:02 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfc.amsl.com (Postfix) with ESMTP id B7FA4E0870 for ; Tue, 12 Apr 2011 12:45:02 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id AACCE202043 for ; Tue, 12 Apr 2011 12:45:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=hoxjY7BRnUdpjpQ+l2t6yZZt4TOiCDDmZwpIRe9SGiPs P2h4n6OWbci5sfXbxswJEFqOmymTVPWHqKSd1wDj51n8F4fuN+J5/yeiGDgKabUG 6he2y/PQHYlrx+2t3OS4DHqtKvAenmA8Vg3PF3BLNF/Hn0w8U7Okm1g4nQvplcU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=R6bh6a5V9yZrP8/k+qWre+Qhxeg=; b=OYONk3ND8A9 RUtJEV2erSTRhDR0Us1/IgD75Jg5CUrj/sqKqK22navtEzsquho+v1HUz9x4HA04 1uDiZKRN6LVLA0oeSWVc77e6CD5au3tCBKVjPF66I4vAuFyuiQOeoR84OFcq+nY+ l+eGn8+9rjWrsfpaWUm74Qa6FAV8FO78= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 7826920203C for ; Tue, 12 Apr 2011 12:45:01 -0700 (PDT) Received: by vws12 with SMTP id 12so6668187vws.31 for ; Tue, 12 Apr 2011 12:45:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.101.168 with SMTP id fh8mr4164192vdb.134.1302637500889; Tue, 12 Apr 2011 12:45:00 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Tue, 12 Apr 2011 12:45:00 -0700 (PDT) In-Reply-To: <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> Date: Tue, 12 Apr 2011 14:45:00 -0500 Message-ID: From: Nico Williams To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Yoav Nir , Tero Kivinen , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 19:45:03 -0000 On Tue, Apr 12, 2011 at 2:39 PM, Dan Harkins wrote: > On Tue, April 12, 2011 11:53 am, Nico Williams wrote: >> On Tue, Apr 12, 2011 at 1:01 PM, Dan Harkins wrote= : >>> On Tue, April 12, 2011 7:38 am, Nico Williams wrote: >>>> I don't get the hostility to pluggable authentication architectures. >>>> Why on Earth should any of us dictate to users what kinds of >>>> authentication infrastructures they must have? >>> >>> =C2=A0We do that when we ship support for some authentication credentia= l >>> in product. Whether it's a particular EAP method or a TLS ciphersuite >>> or support for particular authentication method in IKE. >> >> Who ships credentials? =C2=A0Customers control credentials, not vendors. >> (The only exception is default trust anchors, which are a sort of >> credential.) > > =C2=A0I said _support_ some credential, not ship the credential. If your > product supports EAP-SIM then what I'm saying is you are "dictating to > users what kind of authentication infrastructure they must have", namely > one that supports SIM cards. Oops, sorry I misread that. >> I'm not fond of the proliferation of authentication frameworks. =C2=A0If >> you thought I was, you misunderstood. =C2=A0I'd rather see one framework >> win (which is why we did the SASL/GS2 bridge to GSS-API mechanisms). >> We have all the frameworks that we have because historically various >> groups created them independently, often as a generalization of the >> reality that various protocols were pluggable but without a generic >> framework (this is true of EAP and SASL). =C2=A0And here Tero is proposi= ng >> yet another pluggable framework. >> >> Tero's proposal: create a new pluggable authentication framework. >> My proposal: pick an off-the-shelf framework. >> >> Your proposal: ?? =C2=A0Force a single authentication mechanism on all? > > =C2=A0No no, not at all. Robust and misuse resistance is my proposal. Usi= ng > the best technique directly in the protocol for the chosen credential. > If you want to use certificates then use a certificates in the exchange. > If you want to use a password then use a password in the exchange. But > "lets use X" where X is some pluggable framework is definitely not > my proposal. "If you want to use certs then use certs... if you want to use passwords then use passwords ..." implies an authentication framework with at least two authentication mechanisms (and negotiation!). So you're for at least one authentication framework. Only you weren't aware of it. Or what did I miss this time? :) Nico -- From nico@cryptonector.com Tue Apr 12 13:00:46 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 519FBE08D0 for ; Tue, 12 Apr 2011 13:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0FGyaEn-dTG for ; Tue, 12 Apr 2011 13:00:45 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfc.amsl.com (Postfix) with ESMTP id 68F06E07C4 for ; Tue, 12 Apr 2011 13:00:45 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 97A881B407F for ; Tue, 12 Apr 2011 13:00:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=By76vo1Ga0R7T+UwSd2GjTWDC4bSdgSVB9/qb+a4rtBP 6mXTyHNDOzT2iFqbu4t2LqVhEPjdfq9BEdyjQNidM3GDWSFSV1FELGLxCe52HCbp p9BIt/za9+DG0DYpIvzjh2cnojHHcLexANHG5N0MNH91qE4wn83NFRql4AKAzps= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=FKeERkmQWHG/Kh/dhOg59/uwsYQ=; b=m/nY4xnEYKq Poaa0AYm3TzOkvLp2N2bELYZFTMd8jyID+S1J8UNVNUO4lyU3Q/IDmn8Nh1g5pp+ OI2V3L+1VaV+6cOhtJ3I8fC0OgL8yMWEbfpWkZVBEHtXtDx6sPVXUUQMVVcXGhw3 TgnJluNyS6sOPAzEaFiD1kha+eYhVgjY= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 709931B406E for ; Tue, 12 Apr 2011 13:00:44 -0700 (PDT) Received: by vxg33 with SMTP id 33so6425200vxg.31 for ; Tue, 12 Apr 2011 13:00:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.188.230 with SMTP id gd6mr4628121vdc.294.1302638443852; Tue, 12 Apr 2011 13:00:43 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Tue, 12 Apr 2011 13:00:43 -0700 (PDT) In-Reply-To: <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> Date: Tue, 12 Apr 2011 15:00:43 -0500 Message-ID: From: Nico Williams To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Yoav Nir , Tero Kivinen , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:00:46 -0000 On Tue, Apr 12, 2011 at 2:39 PM, Dan Harkins wrote: > =C2=A0I'm a bit undecided on Tero's proposal. I tend to get in trouble wh= en > I ascribe motivation to things people do so I won't do that, but as > someone who actually implements the protocols we design here I think > having n protocols, where n > 1, to solve a single problem with no clear > "winner" means that for interoperability reasons I have to implement > all n and that's a shame. Since Tero actually implements these protocols > too I think he might share that concern. I strongly disagree with this. I mean, I agree with not wanting to implement N>1 or N>2 mechanisms, but that's the beauty of pluggable frameworks: you publish a plugin SPI and then you can let third parties ship the plugins that you don't care about. The only other alternative that works for customers is "protocol transition", which I'll admit I like as well. Think of SACRED, kx509, PKINIT, and so on. Each of these allows you to use one credential of one type to obtain a temporary credential of another type. > =C2=A0It might be possible to get the authors of the competing drafts to > rely on a common method of identifying the intent of the initiator > (currently PACE uses a Notify and SPSK uses the mandatory bit) and > ensure that their protocols all look the same-- send a blob, get a blob, > send another blob, get another blob-- and to mix results from PAKE > exchange into results of the D-H exchange in a uniform manner and we migh= t > get the equivalent of what he's proposing without Yet Another Pluggable > Architecture (which I guess we both agree would be not-so-good). I'm quite skeptical that you (the IPsec WG in this case) can design a pluggable framework that will only be used for password-based authentication and which will not grow to be yet another pluggable framework with all the issues you dislike (including the need to implement N>1 mechanisms). And yes, we agree that yet another pluggable framework would be bad. I fail to see how Tero's proposal makes any headway. Customers who have and want to use AAA will not be able to use it, near as I can tell, and if you undertake to make it possible to use AAA in Tero's proposal then you'll be quickly approximating EAP re-invention. Thus my skepticism. It's not pessimism because the obvious solution is to use an off-the-shelf solution. > =C2=A0Now the drafts are in LC. Maybe a few comments could get the author= s > to align their drafts so they look architecturally identical while > implementing different exchanges. Which I-Ds are in last call?? From dharkins@lounge.org Tue Apr 12 13:03:41 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7EB11E08A2 for ; Tue, 12 Apr 2011 13:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGPXMYVd+u1g for ; Tue, 12 Apr 2011 13:03:40 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfc.amsl.com (Postfix) with ESMTP id CAB96E0879 for ; Tue, 12 Apr 2011 13:03:40 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E25E61022404C; Tue, 12 Apr 2011 13:03:39 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 12 Apr 2011 13:03:40 -0700 (PDT) Message-ID: <0cd4b6cb67929c99216df8af08505d4e.squirrel@www.trepanning.net> In-Reply-To: References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> Date: Tue, 12 Apr 2011 13:03:40 -0700 (PDT) From: "Dan Harkins" To: "Nico Williams" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Yoav Nir , Dan Harkins , Tero Kivinen , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:03:41 -0000 Hi Nico, On Tue, April 12, 2011 12:45 pm, Nico Williams wrote: > "If you want to use certs then use certs... if you want to use > passwords then use passwords ..." implies an authentication framework > with at least two authentication mechanisms (and negotiation!). > > So you're for at least one authentication framework. Only you weren't > aware of it. Or what did I miss this time? :) No I don't think you missed it. The "framework" is just IKE and if we want to use a credential in IKE we should use it directly and in the most robust and misuse resistant way possible. In my opinionated opinion, putting a pluggable framework, like EAP, into IKE was a mistake and putting in another to use some particular credential would compound that mistake. regards, Dan. From yaronf.ietf@gmail.com Tue Apr 12 13:13:20 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 71B13E08A8 for ; Tue, 12 Apr 2011 13:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwEu2gv0PBOF for ; Tue, 12 Apr 2011 13:13:19 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 922AAE06BC for ; Tue, 12 Apr 2011 13:13:19 -0700 (PDT) Received: by wyb29 with SMTP id 29so6648371wyb.31 for ; Tue, 12 Apr 2011 13:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OJK4nvFVBOqQUshDUhf1LLW+c0Cny9yK2xpEd0HimHk=; b=myxbFiksgJwn0JQZ7eO42KIzPsT84JwB2YkNbRiVltPp3XP/z17Xiy/3oTT2Q4M0Qf 6yQ8zfPE2R7pMZcks2Y+0BlcUBGeN3wWwD0+UrSa7n/XTBf83f0h4swhyoidh42zhy+h dLd4uWbAq44DfFdqjLgCERZcIGwJdUaYIY96Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=dYuzUdyHgyQ+/yeMCXJYAZEIHcAPrY6RR2zwdrS9h016zQVqhiivHNS/9Bejj/8yND G9YadSElFE4DjDOOmJAB4rQwmNNENjnHKkLGlQCqk+sMFicZ8iy0/UyqKb/KXy38p/ea dLdgrY630YF8z2waJNjeXSCC/cJjU/MZ75vDU= Received: by 10.216.80.207 with SMTP id k57mr4511880wee.12.1302639198945; Tue, 12 Apr 2011 13:13:18 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-177-21-107.red.bezeqint.net [79.177.21.107]) by mx.google.com with ESMTPS id z13sm4251520wbd.63.2011.04.12.13.13.15 (version=SSLv3 cipher=OTHER); Tue, 12 Apr 2011 13:13:17 -0700 (PDT) Message-ID: <4DA4B259.1050809@gmail.com> Date: Tue, 12 Apr 2011 23:13:13 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Dan Harkins References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> In-Reply-To: <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Yoav Nir , Tero Kivinen , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" , Nico Williams Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:13:20 -0000 Hi, I'd like to skip through the architectural bits in a hurry, and then come back to Tero's proposal. All while rapidly flipping hats :-) In the past I was of the opinion that IKEv2+EAP (with Mutual EAP, RFC 5998) could get us all we need for password authentication, and eliminate the use of insecure "shortened shared secrets" (abused PSK) in IKEv2. An implementer could use Dan's EAP-pwd or my EAP-EKE (now both published as RFCs) and be done. The WG consensus was that we need specific IKE auth methods, because implementing EAP is a pain in some situations. I have accepted this consensus and I see no reason to reopen this discussion. [WG co-chair hat off:] Unfortunately we had just enough energy to decide that we want a "native IKEv2" way to do authentication with short secrets; we did not have enough energy to pick a winner method. And I don't think we as a WG, or the authors of the individual proposals, have the energy to go through a "framework" exercise at this point in time. The documents are now in IETF LC after having been held up for more than half a year. Now to Tero's proposal: I'm afraid it is too much of an abstraction for what we really need to achieve. I am as unhappy as anybody that we could not settle on a single method, but this is water under the bridge. Given this situation, we want to minimize the pain for implementors who implement 1-2 of these methods (I have abandoned HUSH in favor of PACE a while ago, and I somehow don't see anybody implementing all three). So I don't think we need a whole framework. We just need a way for the two peers to negotiate which method(s) they support early enough, i.e. in IKE_SA_INIT. In PACE we use a notification, and I strongly urge the two other documents' authors to do the same. But I'm willing to be convinced to switch to another method if that's the group's preference. Other than that, I really don't see the value in uniform "meta-payloads" and "super-notifications", or how they would simplify implementations. Thanks, Yaron From dharkins@lounge.org Tue Apr 12 13:18:41 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2A372E0903 for ; Tue, 12 Apr 2011 13:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrleVQbJ9Kgv for ; Tue, 12 Apr 2011 13:18:40 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfc.amsl.com (Postfix) with ESMTP id 58C90E0870 for ; Tue, 12 Apr 2011 13:18:40 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C24CF1022404C; Tue, 12 Apr 2011 13:18:39 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 12 Apr 2011 13:18:39 -0700 (PDT) Message-ID: In-Reply-To: References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> Date: Tue, 12 Apr 2011 13:18:39 -0700 (PDT) From: "Dan Harkins" To: "Nico Williams" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Yoav Nir , Tero Kivinen , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:18:41 -0000 Hi Nico, On Tue, April 12, 2011 1:00 pm, Nico Williams wrote: > I fail to see how Tero's proposal makes any headway. Customers who > have and want to use AAA will not be able to use it, near as I can > tell, and if you undertake to make it possible to use AAA in Tero's > proposal then you'll be quickly approximating EAP re-invention. Thus > my skepticism. It's not pessimism because the obvious solution is to > use an off-the-shelf solution. See that's the whole thing! You can't use AAA because IKE is not a client-server protocol designed for network access (although some people try to use it for that). Each side can initiate to the other so each side needs access to the credential and since there's no way for a AAA server to initiate EAP to another AAA server you can't use AAA. And if you can't use AAA then what's the point of using EAP? There isn't one! It's a pointless encapsulation that increases the number of messages and invites insecure misuse of IKE. I fail to see any value that a pluggable authentication framework adds. (EAP re-invention might be a good idea. Maybe someone can make it so a self-described authentication protocol has way of learning an identity that is useful for authentication purposes. And if a message can get big enough to be fragmented then maybe defining fragmentation/reassembly might be a good idea too. Both of those tend to get reinvented with each EAP method that needs them-- ggrrrrr). >>  Now the drafts are in LC. Maybe a few comments could get the authors >> to align their drafts so they look architecturally identical while >> implementing different exchanges. > > Which I-Ds are in last call?? The three PAKE I-Ds: - draft-harkins-ipsecme-spsk-auth - draft-kuegler-ipsecme-pace-ikev2 - draft-shin-augmented-pake regards, Dan. From nico@cryptonector.com Tue Apr 12 13:37:22 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A2C37E0870 for ; Tue, 12 Apr 2011 13:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zABKkb8+VplK for ; Tue, 12 Apr 2011 13:37:20 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfc.amsl.com (Postfix) with ESMTP id 4C198E0688 for ; Tue, 12 Apr 2011 13:37:20 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id D0609598065 for ; Tue, 12 Apr 2011 13:37:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=jvbanjmPDrNfCXDC5HT0QrC8Sgv9oKjQ5XZPlfLNjhIQ d89N2Q0zTjxf5MygJgeFVCTEyLsmzeSMOgvobUbND3qnKqPGqlgaGEJcykYQh4Mw tMDdRLJco3rXePoFqfsgzLqG1g/8iHcY/zbOvC8ZESsuZYDoZDSuoyH13LV7Vvo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=hYY1JuqNYQ5vyIPgdsaJUBYgFag=; b=hQc2QeoEdw0 6pV2jjHh3MXxR1hNFdMzIoiKpjlVsIboLSCATIx48lOz2LgMJ+VzJUBb106Lqv75 TbWyWcoGqfmIEkgWnt+D1G/Gf9KvZwR4ADyp1Lm67Yizub0OqGaF3NGBxNWoc83F 9UsXB0OxO0ksXNozUo+mkMesaoQN2W20= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id A5830598057 for ; Tue, 12 Apr 2011 13:37:18 -0700 (PDT) Received: by vws12 with SMTP id 12so6720274vws.31 for ; Tue, 12 Apr 2011 13:37:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.130 with SMTP id l2mr5288597vdv.14.1302640637858; Tue, 12 Apr 2011 13:37:17 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Tue, 12 Apr 2011 13:37:17 -0700 (PDT) In-Reply-To: <0cd4b6cb67929c99216df8af08505d4e.squirrel@www.trepanning.net> References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> <0cd4b6cb67929c99216df8af08505d4e.squirrel@www.trepanning.net> Date: Tue, 12 Apr 2011 15:37:17 -0500 Message-ID: From: Nico Williams To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Yoav Nir , Tero Kivinen , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:37:22 -0000 On Tue, Apr 12, 2011 at 3:03 PM, Dan Harkins wrote: > On Tue, April 12, 2011 12:45 pm, Nico Williams wrote: >> So you're for at least one authentication framework. =C2=A0Only you were= n't >> aware of it. =C2=A0Or what did I miss this time? :) > > =C2=A0No I don't think you missed it. The "framework" is just IKE and if > we want to use a credential in IKE we should use it directly and in the > most robust and misuse resistant way possible. In my opinionated opinion, > putting a pluggable framework, like EAP, into IKE was a mistake and > putting in another to use some particular credential would compound that > mistake. I can understand your frustration with EAP... but look, SSHv2 also has its own framework and... we ended up adding the option to use another framework because it was easier that way to add support for all the authentication mechanisms that we needed in SSHv2. I predict exactly the same progression will happen here, if you go down this path. So what do we gain? Well, there is expediency -- you might implement and deploy something very quickly that works for a few people now who need this now. Expediency is not a laughable argument, so I won't be too upset if that's the argument that gets invoked here. But if we can foresee that this framework will grow and need the same sorts of mechanisms that are available elsewhere... why not do it the Right Way (tm) from the get go? From nico@cryptonector.com Tue Apr 12 13:48:24 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7730CE07DB for ; Tue, 12 Apr 2011 13:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZbZ8UZ8tPfS for ; Tue, 12 Apr 2011 13:48:23 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfc.amsl.com (Postfix) with ESMTP id 6D27FE06BC for ; Tue, 12 Apr 2011 13:48:23 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id BBEE343807C for ; Tue, 12 Apr 2011 13:48:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Dinv1rSZQ/hlY7TiLnZDvHIGFCI9ztuo5XkwwdUqo9kQ bEJHKa+A2twepIdvGnP/m5jlTa4zsZhT/ovdAO51eQLDepAdc1kXInzjK4Jlqpy2 31KD/sAWYPvpCl1uMtk5RGc3q/bCyI986vzf+9jvoac7MykE4tTRRa8hfiFUj1w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=2ledTYWOdVgRIIwE5Ka3rzgR3EE=; b=EMQtKn2+PV6 aphFiY1WSDVr9BT4VwaX6O3m74uGVpFbZbdUO+QXn3CBu7fBOh1uCDBRTFoVQ8u6 5O5gCZV52FZbwuOYYb2i5J6ymLaQJ2oqOTL7yAQFUE2bH3wiUTXUt2FGmI8x35PG Hg+BSoYbNVhoeSh+jl7X0QtYUrUITuLU= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 846B9438072 for ; Tue, 12 Apr 2011 13:48:22 -0700 (PDT) Received: by vxg33 with SMTP id 33so6470459vxg.31 for ; Tue, 12 Apr 2011 13:48:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.188.230 with SMTP id gd6mr4702457vdc.294.1302641301916; Tue, 12 Apr 2011 13:48:21 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Tue, 12 Apr 2011 13:48:21 -0700 (PDT) In-Reply-To: References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> Date: Tue, 12 Apr 2011 15:48:21 -0500 Message-ID: From: Nico Williams To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Yoav Nir , Tero Kivinen , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:48:24 -0000 On Tue, Apr 12, 2011 at 3:18 PM, Dan Harkins wrote: > On Tue, April 12, 2011 1:00 pm, Nico Williams wrote: >> I fail to see how Tero's proposal makes any headway. =C2=A0Customers who >> have and want to use AAA will not be able to use it, near as I can >> tell, and if you undertake to make it possible to use AAA in Tero's >> proposal then you'll be quickly approximating EAP re-invention. =C2=A0Th= us >> my skepticism. =C2=A0It's not pessimism because the obvious solution is = to >> use an off-the-shelf solution. > > =C2=A0See that's the whole thing! You can't use AAA because IKE is not a > client-server protocol designed for network access (although some people > try to use it for that). Each side can initiate to the other so each > side needs access to the credential and since there's no way for a AAA > server to initiate EAP to another AAA server you can't use AAA. And if > you can't use AAA then what's the point of using EAP? There isn't one! > It's a pointless encapsulation that increases the number of messages and > invites insecure misuse of IKE. I fail to see any value that a pluggable > authentication framework adds. > > =C2=A0(EAP re-invention might be a good idea. Maybe someone can make it s= o > a self-described authentication protocol has way of learning an identity > that is useful for authentication purposes. And if a message can get big > enough to be fragmented then maybe defining fragmentation/reassembly > might be a good idea too. Both of those tend to get reinvented with each > EAP method that needs them-- ggrrrrr). I was just about to say the same thing regarding EAP re-invention :) I'd just neatly side-step the whole issue by using the GSS-API. Why? Because: a) you PAKEs are easy to specify as GSS-API mechanisms, so going the GSS way doesn't hurt, b) the GSS-API has an abstract API, which will lead to better PAKE mechanism design (e.g., regarding principal naming) and also better code design (because the GSS pattern is eminently reusable), c) if anyone wants AAA you point them to the ABFAB WG's work (and, if you must, hold your nose). Tell me: why not GSS? Oh, and by the way, I can prove that it's fairly easy to specify a GSS PAKE: just go read RFC5802, which defines one (SCRAM -- not a ZKPP, but good enough for you to use as a guide). SCRAM was designed to be specified as simply as possible, with as little reference to the GSS-API as possible, and with such references as boiler-plate as possible. I believe we succeeded. Moreover, SCRAM is both, a SASL and GSS mechanism, and this duality was not difficult to produce because the SASL->GSS bridge was also designed to be as simple and unobstrusive as possible. I urge (beg?) you to read RFC5802 _then_ RFC5801. You should find that RFC5802 (SCRAM) is comprehensible without much reference to GSS-API and SASL concepts, while RFC5801 (SASL/GS2) requires knowledge of GSS concepts. You don't need to implement RFC5801, not even RFC4422 (SASL) in order to implement SCRAM! That's the best part. I'm hoping that you'll agree with me that the SCRAM approach, substituting any PAKE's guts into it, is a good one. >>> =C2=A0Now the drafts are in LC. Maybe a few comments could get the auth= ors >>> to align their drafts so they look architecturally identical while >>> implementing different exchanges. >> >> Which I-Ds are in last call?? > > =C2=A0The three PAKE I-Ds: > > =C2=A0 - draft-harkins-ipsecme-spsk-auth > =C2=A0 - draft-kuegler-ipsecme-pace-ikev2 > =C2=A0 - draft-shin-augmented-pake Thanks. I'll take a look. I bet these can all be very easily turned into SASL and GSS mechanisms ala SCRAM without doing too much violence to them. Nico -- From nico@cryptonector.com Tue Apr 12 14:03:26 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DCA95E0904 for ; Tue, 12 Apr 2011 14:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaHCtehObJST for ; Tue, 12 Apr 2011 14:03:26 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfc.amsl.com (Postfix) with ESMTP id 19A51E07D4 for ; Tue, 12 Apr 2011 14:03:26 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 6A15F6B007C for ; Tue, 12 Apr 2011 14:03:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=fgM3dAtpnliIzBc4lyZeu yDuPbiuVg3C2tcL9e2ZWMQ5DE7FGo1vGmRdpBghzW/2QzuyaiyryYR3UgToWwZYd /41Gp6UzdNxSCgKvPH+uCqFnvRzRLH/KI7xyF5YzotpHLIjymxbzVHpau7+Ohwz5 ugv1moIk0fg+LMDbXOCKLU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=RPgGG0XcnM+suxFzZLaG aFrdX7E=; b=mvLTAUEHUphzpkh195Ne/piKR44df73SMHGUYtl4QRxwtj/kWh1S /sHQCZ1U9TPazHEc9ZFME4KibMhpbSbRvrncM1/eGpMDRxy0znSj3rtY2D0b8aa+ jvBSPWNfjn/3sjANdlrWO/3rNN8a1peN0SH1+i/LTFSxWBQxTlQFuLA= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 3B9596B0070 for ; Tue, 12 Apr 2011 14:03:25 -0700 (PDT) Received: by vws12 with SMTP id 12so6742770vws.31 for ; Tue, 12 Apr 2011 14:03:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.8 with SMTP id eq8mr1665204vdc.214.1302642204585; Tue, 12 Apr 2011 14:03:24 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Tue, 12 Apr 2011 14:03:24 -0700 (PDT) In-Reply-To: <4DA4B259.1050809@gmail.com> References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> <4DA4B259.1050809@gmail.com> Date: Tue, 12 Apr 2011 16:03:24 -0500 Message-ID: From: Nico Williams To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Cc: Yoav Nir , Dan Harkins , Tero Kivinen , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 21:03:27 -0000 On Tue, Apr 12, 2011 at 3:13 PM, Yaron Sheffer wrote: > I'd like to skip through the architectural bits in a hurry, and then come > back to Tero's proposal. All while rapidly flipping hats :-) :) > In the past I was of the opinion that IKEv2+EAP (with Mutual EAP, RFC 5998) > [EAP pain elided -Nico] Undcerstood. And from the discussion with Dan I think I've come to see that there's actually very little difference between what Tero proposes and what I would consider ideal, which, if I may, would be: - Initiator<->Responder: KE payload exchange - Initiator->Responder: {SASL/GS2 mechanism name list, [initial context token for optimistic mechanism choice, with channel binding to KE]} - Responder->Initiator: {Server's SASL/GS2 mechanism name list} | reply context token for optimistic mechanism choice, with channel binding to KE - Initiator<->Responder: variable number of round-trips, according to the selected mechanism - done And what do the mechanisms look like? Easy: look at SCRAM (RFC5802). SCRAM is a simple successor to DIGEST-MD5. IKE would need other mechanisms too, but all of those could be patterned after SCRAM in terms of specification simplicity. If you do it this way you needn't even be too aware that you're actually using the GSS-API framework -- you can ignore it almost completely. But the rest of us will get working SASL and GSS mechanisms out of your IKE mechanisms. Win-win for all of us. And if anyone ever needs AAA? Point them to ABFAB. Nico -- From nico@cryptonector.com Tue Apr 12 14:25:13 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F0F06E0980 for ; Tue, 12 Apr 2011 14:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHAxpMA5HHp2 for ; Tue, 12 Apr 2011 14:25:13 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfc.amsl.com (Postfix) with ESMTP id D4827E0981 for ; Tue, 12 Apr 2011 14:25:12 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id DE835350072 for ; Tue, 12 Apr 2011 14:25:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=WK94tMVxo+tlExC5QECax EmLKdoGQvmYGV3iTgtizj66n0Y314+xeW5PsfmzqLKpsj3NVzlGTrNFPRWUUq7DP Jwr3KM6CjLTckheO1PWvhQE5Sk6UJDoNGwqFIvzqV+mHva99nRQYjnTn6yQ3KniF +3MP9yVbWm3RJrkPoBNoDw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=6q3zldgspkp5GtJ9PkS8 Kx19B2E=; b=Yh3LFtrE5k9TDhl8DptiWoXHuVhdKgPU+uZYKtmFfx/P13F1sZ/0 DrJ/NVElvoBSooNgx8IJ77eWLhsDQT0T4UXtpwble9TqL5ZWCzIN715n5Vcve5W4 BNi14QJJV9Q8pGqV1NxvBIXVVteW3VFFoA3/R+/9sa4HEs5yOlTCoQI= Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 86665350063 for ; Tue, 12 Apr 2011 14:25:11 -0700 (PDT) Received: by wyb29 with SMTP id 29so6699766wyb.31 for ; Tue, 12 Apr 2011 14:25:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.245.6 with SMTP id n6mr4568034wer.40.1302643510048; Tue, 12 Apr 2011 14:25:10 -0700 (PDT) Received: by 10.216.64.74 with HTTP; Tue, 12 Apr 2011 14:25:08 -0700 (PDT) Received: by 10.216.64.74 with HTTP; Tue, 12 Apr 2011 14:25:08 -0700 (PDT) In-Reply-To: References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> <4DA4B259.1050809@gmail.com> Date: Tue, 12 Apr 2011 16:25:08 -0500 Message-ID: From: Nico Williams To: Nico Williams Content-Type: multipart/alternative; boundary=e0cb4e43cd31af79e404a0bf53b9 Cc: Yoav Nir , Dan Harkins , Tero Kivinen , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 21:25:14 -0000 --e0cb4e43cd31af79e404a0bf53b9 Content-Type: text/plain; charset=UTF-8 And if the mechanism does strong KE then you don't lose a round-trip nor do channel binding as in my previous example. The differences between Tero's and my proposal, then are pretty simple: - the way mechanisms are named; - names are sent in each mech's messages, not in separate IKE payloads; - weaker PAKEs, like SCRAM would be used with channel binding to an IKE KE exchange (while stronger ones simply output key material, avoiding the need for an IKE KE). That's it. Also, my way you'd be using the GSS-API framework, but you wouldn't have to be aware of that :) Nico -- --e0cb4e43cd31af79e404a0bf53b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

And if the mechanism does strong KE then you don't lose a round-trip= nor do channel binding as in my previous example.

The differences between Tero's and my proposal, then are pretty simp= le:

- the way mechanisms are named;
- names are sent in each mech's messages, not in separate IKE payloads= ;
- weaker PAKEs, like SCRAM would be used with channel binding to an IKE KE= exchange (while stronger ones simply output key material, avoiding the nee= d for an IKE KE).

That's it.=C2=A0 Also, my way you'd be using the GSS-API framewo= rk, but you wouldn't have to be aware of that :)

Nico
--

--e0cb4e43cd31af79e404a0bf53b9-- From yaronf.ietf@gmail.com Tue Apr 12 23:20:36 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9541AE06D1 for ; Tue, 12 Apr 2011 23:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prtQPvg-odGH for ; Tue, 12 Apr 2011 23:20:35 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 70A29E065A for ; Tue, 12 Apr 2011 23:20:35 -0700 (PDT) Received: by wyb29 with SMTP id 29so234127wyb.31 for ; Tue, 12 Apr 2011 23:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o2QRN8LL7JF7hzBOvxJQJrfwEG5sp+LfYy+9Kw0PdiM=; b=pnVsQoqM36666RzijVLaeWoVnh4u/cgvPHvXKPBMfV/mhYSSVPFuXRDVg6Id2/18v2 7YI0RdfMQmj2eVZFj/A2MyvMmXCk+pZbHjsuQz7LWwcWNEXI0iDMzODkcbzJz/VKkzBH kbjOBKaElUeiZ9CQV2aFZWAn67+PldRA02jrs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=L5uG6zvjeC/It2kk7zlFENvxgJFBX34Uw3fP+TPzj8S0S/4eCqGO5L1nvlU9mITBS6 1ZEOWDCqRl3StdEh9kRJZXgnPtxq5gx38Hy8B9LTRinu1SUz+aia0Y3imEZ8NURP1zTf bd+UHpAXP9DeWEJuW/gKbdA0qruaeuks3ea44= Received: by 10.227.197.210 with SMTP id el18mr7524209wbb.39.1302675634597; Tue, 12 Apr 2011 23:20:34 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-177-21-107.red.bezeqint.net [79.177.21.107]) by mx.google.com with ESMTPS id bd8sm115600wbb.14.2011.04.12.23.20.30 (version=SSLv3 cipher=OTHER); Tue, 12 Apr 2011 23:20:33 -0700 (PDT) Message-ID: <4DA540AC.1060909@gmail.com> Date: Wed, 13 Apr 2011 09:20:28 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Dan Harkins References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> In-Reply-To: <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Yoav Nir , Tero Kivinen , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" , Nico Williams Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 06:20:36 -0000 Hi Dan, as you say below, PACE uses a notification for the initiator to indicate its support of the protocol. In fact, both sides get a chance to indicate their support. SPSK uses the Critical (a.k.a. Mandatory) bit for the initiator to indicate this support, and relies on an error indication from the responder if the responder doesn't like the protocol. While the SPSK mechanism sort of works in an SPSK-only world, it makes the life of implementations that want to support multiple methods much harder. Suppose that Alice wants to talk to Bob. Alice supports PACE, SPSK and even EAP-pwd, but has no idea what Bob supports. After the IKE_SA_INIT exchange, Alice will know if Bob supports PACE, but will not know if he supports SPSK (EAP method negotiation is another can of worms, let's leave it for another day). So Alice embarks on the IKE_AUTH exchange with only partial knowledge. If Alice now initiates SPSK (by sending COMi), but it turns out that Bob does not support it after all, Bob will reply with an UNSUPPORTED_CRITICAL_PAYLOAD. Alice will now have to restart the whole exchange with the knowledge of Bob's abilities. This is certainly more complex than doing it all within the same exchange. Moreover, since authentication never completed, Bob's response is subject to an undetected downgrade attack. Alice would be eternally grateful if an SPSK_SUPPORTED notification were added into the IKE_SA_INIT exchange :-) I'm not sure if there's any valid use for the Critical bit (i.e. for non-critical payloads in IKEv2), but negotiating an authentication method doesn't appear to be such use. Thanks, Yaron > > It might be possible to get the authors of the competing drafts to > rely on a common method of identifying the intent of the initiator > (currently PACE uses a Notify and SPSK uses the mandatory bit) and > ensure that their protocols all look the same-- send a blob, get a blob, > send another blob, get another blob-- and to mix results from PAKE > exchange into results of the D-H exchange in a uniform manner and we might > get the equivalent of what he's proposing without Yet Another Pluggable > Architecture (which I guess we both agree would be not-so-good). > > Now the drafts are in LC. Maybe a few comments could get the authors > to align their drafts so they look architecturally identical while > implementing different exchanges. > > regards, > > Dan. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Wed Apr 13 03:25:30 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 75B13E0682 for ; Wed, 13 Apr 2011 03:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kh028CJNnbrc for ; Wed, 13 Apr 2011 03:25:29 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9B7FAE0613 for ; Wed, 13 Apr 2011 03:25:29 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p3DAOlhU001120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 13:24:47 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p3DAOjB6024781; Wed, 13 Apr 2011 13:24:45 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19877.31213.32508.177795@fireball.kivinen.iki.fi> Date: Wed, 13 Apr 2011 13:24:45 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: "ipsec@ietf.org" , "dennis.kuegler@bsi.bund.de" , "dharkins@arubanetworks.com" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:25:30 -0000 Yoav Nir writes: > I have mixed feelings about this. It's better than all four of those > drafts advancing separately. OTOH this plug-innable architecture is > pretty much admitting defeat. It sets us up to have a situation like > EAP, with lots of different methods, and no guide to implementers as > to which methods to implement. I agree on that, and as I stated in my email we did fail in WG... > But I guess it's the lesser evil. Thats the idea. I think the worst situation is if all of the 4 drafts gets published as RFC as they are now and then implementors will be even more lost which one to implement. Trying to convince even some of those draft authors to merge their proposal, or pick one of the others seems to be impossible. -- kivinen@iki.fi From kivinen@iki.fi Wed Apr 13 03:53:33 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 68209E06BB for ; Wed, 13 Apr 2011 03:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDHRdIi4UFuD for ; Wed, 13 Apr 2011 03:53:32 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2EB57E0692 for ; Wed, 13 Apr 2011 03:53:32 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p3DAr9jH028661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 13:53:09 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p3DAr8F4026435; Wed, 13 Apr 2011 13:53:08 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19877.32916.912580.889246@fireball.kivinen.iki.fi> Date: Wed, 13 Apr 2011 13:53:08 +0300 From: Tero Kivinen To: Nico Williams In-Reply-To: References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 12 min Cc: ipsec@ietf.org, dennis.kuegler@bsi.bund.de, dharkins@arubanetworks.com, seonghan.shin@aist.go.jp, sfluhrer@cisco.com Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:53:33 -0000 Nico Williams writes: > We already have three generic authentication frameworks: SASL, > GSS-API, and EAP. Must we add a fourth one? (We also have a number > of less generic ones, such as the ones in SSHv2, TLS, ...). I do not consider this to be generic authentication framework. I consider this being IKEv2 payload format for encapsulating different secure password authentication methods to the IKEv2 so those different methods can co-exist in the same implementation without lots of extra code. > Considering that: a) we have EAP in IKEv2, Which WG decided was not enough for secure password authentication because it was not symmetric especially in the implementation side. The secure password authentication method we are trying to add needs to be completely symmetric i.e. either end can start sessions without any problems from the authentication methods point of view. Most of the IKEv2 implementations only support EAP client side or EAP server side but not both at the same time. Also if you want to support EAP server side in both ends of the VPN gateway to gateway communication you need EAP AAA infrastructure in both ends too, which is not usually the case or you need to implement the EAP AAA infrastructure inside the VPN gateway, which also is not usually done. > b) there are reserved numbers for using the GSS-API in IKEv1, and we > could make it usable in IKEv2, If I remember right GSS-API is also asymmetric meaning only there is clear separation of client and server side, and usually you cannot assume that if I can act as GSS-API client side and connect to the server the implementation can also act as GSS-API server side. I might be wrong on that issue, as I do not know GSS-API that well. Also getting all those 4 secure password authentication methods convereted to GSS-API methods is going to require quite a lot of work, and also binding GSS-API authentication to the IKEv2 authentication also requires work. In this system I proposing I do plan to leave those details for the mehods themselves, i.e. the methods need to describe what kind of payloads are sent inside the generic payload, and how the AUTH payload sent inside the IKEv2 needs to be calculated to do the authentication. The generic framework just offers common way to agree on the method to be used, and provide generic payload format for transmitting the methods specific payloads. > c) we have a plethora of EAP methods and GSS-API mechanisms > available now or soon, ... why create a new framework? Because WG needs to have symmetric secure password authentication method. We wanted to have one, but unfortunately we failed and now it looks we are going to have multiple, and those different methods as written now do not co-exist nicely, and every single one of them do require modifications to the standard IKEv2. If we create common payload format which those methods can use, and common way to agree on which method to use, then the IKEv2 protocol modifications need to be done only once, and the method specific code can be in separate module. This module will still tightly integrate to the IKEv2, as it changes number of exchanges, and adds payloads to the messages, and also affects how the AUTH payload in the IKEv2 is calculated, but at least the basic code can be shared between different methods. -- kivinen@iki.fi From kivinen@iki.fi Wed Apr 13 04:10:12 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D3B0EE06CD for ; Wed, 13 Apr 2011 04:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4gzZ-R1pIN0 for ; Wed, 13 Apr 2011 04:10:11 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7C757E0692 for ; Wed, 13 Apr 2011 04:10:11 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p3DB9Qh5025906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 14:09:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p3DB9QVq000278; Wed, 13 Apr 2011 14:09:26 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <19877.33893.967502.210752@fireball.kivinen.iki.fi> Date: Wed, 13 Apr 2011 14:09:25 +0300 From: Tero Kivinen To: Nico Williams In-Reply-To: References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 14 min Cc: ipsec@ietf.org, dennis.kuegler@bsi.bund.de, dharkins@arubanetworks.com, seonghan.shin@aist.go.jp, sfluhrer@cisco.com Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:10:13 -0000 Nico Williams writes: > On Tue, Apr 12, 2011 at 7:17 AM, Tero Kivinen wrote:= > > 1) Add new notification to the IKE=5FSA=5FINIT telling which SPAM > > =A0 algorithms are supported. This will notification will include t= uple > > =A0 of 8-bit integers containing the 8-bit SPAM algorith number and= > > =A0 8-bit password preprosessing technique number. The initiator se= nds > > =A0 all supported algorithms and responder will pick one algorithm > > =A0 which is to be used. The other option here is that reponder lis= ts > > =A0 which algorithms which it supports and initiator can then use a= ny > > =A0 of them. >=20 > 8-bit=3F! BTW, sending SASL mechanism names, or EAP method names, or= > GSS-API mechnism OIDs wouldn't be that different from sending 8-bit > mechanism numbers. We currently have 4 different methods, and I do think we are going to be loose one (hopefully two) before they are published as RFCs. I do not really think there are going to be more in next 5 years.=20 > But it'd be way better, because you'd be using an > off-the-shelf framework. Off the shelf is good, for all the reasons = I > gave earlier and then some (more mechanisms exist, the frameworks hav= e > a better chance of being pluggable as implemented, code reuse, > specification reuse, ...) More is bad. We do not want more. We want less. We would like to have exactly ONE method, but we could not agree on one, and as document authors wanted to publish their methods we are now getting four incompatible, non-interoperable methods which are hard to put in same implementation as they do not have common method of agreeing which method to use etc. Every single one of those methods DO require changes to the IKEv2 library. Most likely you cannot make them really pluggable as they do change the fundamental parts of the IKEv2, or at least the API between them and the IKEv2 library is going to be quite complex. Most likely the API will change a bit depending which method is used, for example the AUTH calculation do require lots of stuff from the IKEv2 library, but also lots of stuff from the auth mehtod which means most likely the easiest way is to give all data IKEv2 has to the method specific function which will then do the AUTH calculation. This is not going to be anything generic, but data from IKEv2 that needs to be given to the method might differ from method to method. Note, that this changes the IKE=5FSA=5FINIT payload, which MUST be kept= as small as possible so it will not get fragmented. > > 3) The IKE=5FSA=5FINIT and IKE=5FAUTH are used as exchange types, b= ut the > > =A0 extra payloads in them depend on the SPAM algorithm used, and t= he > > =A0 SPAM algorithm used also affects the AUTH payload generation. T= he > > =A0 exchange will similar to EAP, i.e.: >=20 > AUTH payloads should be where channel binding is done, yes. We shoul= d > definitely think in terms of CB here, and if you were to use SASL or > the GSS-API then you'd get the necessary CB functionality right off > the bat. There is no CB there, as the IKEv2 AUTH payload calculation does all the authentication and the AUTH payload calculation done by all of those methods MUST meet exactly same security properties that IKEv2 AUTH payload calculation has, i.e. provide same security than what is explained in the section 2.15 in RFC5996. This is not really external authentication framework, this is integral part of the IKEv2 authentication where we just create generic framework for transmitting those payloads needed by the authentication method. The authentication method is still doing all the AUTH payload calculations using the internal data from the IKEv2 (including InitiatorSignedOctects and ResponderSignedOctects etc).=20 > (Incidentally, your design also reminds me of SSHv2.) The design comes directly from those four different drafts, i.e. I just checked out what is common with them and created the common payload format based on that.=20 --=20 kivinen@iki.fi From kivinen@iki.fi Wed Apr 13 04:33:20 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B0C6EE0743 for ; Wed, 13 Apr 2011 04:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.939 X-Spam-Level: X-Spam-Status: No, score=-101.939 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNpe133iM6gN for ; Wed, 13 Apr 2011 04:33:20 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfc.amsl.com (Postfix) with ESMTP id C3291E068E for ; Wed, 13 Apr 2011 04:33:18 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p3DBUXw0019749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 14:30:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p3DBUWhq026240; Wed, 13 Apr 2011 14:30:32 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19877.35160.192795.560283@fireball.kivinen.iki.fi> Date: Wed, 13 Apr 2011 14:30:32 +0300 From: Tero Kivinen To: Nico Williams In-Reply-To: References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 17 min Cc: Yoav Nir , Dan Harkins , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:33:20 -0000 Nico Williams writes: > Reading into what you write above you seem to think that it's not > possible to abstract authentication sufficiently well (for IKEv2's > purposes, in this case). I disagree. I'll grant only that there's We do have abstract authentication method already in the IKEv2, i.e. EAP. The problem with that is that it do require infrastructure, which is bit too difficult to put up when only thing you want to do is to do shared key authentication between two VPN gateways. > framework (this is true of EAP and SASL). And here Tero is proposing > yet another pluggable framework. Nope. I am not proposing to create pluggable framework. I am proposing of getting common parts of the 4 different methods and make them so they can be used together. > Tero's proposal: create a new pluggable authentication framework. > My proposal: pick an off-the-shelf framework. That one is not really an option. The options are: Tero's proposal: make different symmetric secure password authentication methods so they all can be implemented in the same code base. Other proposal: do nothing, and publish those four different methods so that you need to manually configure which one of them to use and implement new exchanges, payload formats etc for each of them. In both cases the methods are still going to be very tightly combined to the IKEv2, and cannot be separated from there and used elsewhere. The actual algorithms can be used, but the calculations like: found = 0 counter = 1 do { ske-seed = prf(Ni | Nr, psk | counter) ske-value = prf+(swd-seed, "IKE SKE Hunting And Pecking") if (ske-value < p) then SKE = ske-value ^ ((p-1)/r) mod p if (SKE > 1) then found = 1 fi fi counter = counter + 1 } while (found == 0) or skey = F(scalar-op(private, element-op(peer-element, scalar-op(peer-scalar, SKE)))) ss = prf(Ni | Nr, skey | "Secure PSK Authentication in IKE") AUTH = prf(ss, ) or PACESharedSecret = KA(SKEi, PKEr, GE) = KA(SKEr, PKEi, GE), AUTHi = prf(prf+(Ni | Nr, PACESharedSecret), | PKEr) are not really generic, they are specific to the IKEv2. This is not generic authentication framework, this is generic payload format for the IKEv2 secure password authentication methods. The reason WG wanted this is that people want to have secure way to use secure password authentication between boxes. Usually there will NOT be any kind of backend in either end, and the connection will be symmetric, i.e. either end can start it. Normal use case will be the VPN connection between two offices. They do not want any infrastructure, thus they do not want certificates, they do not want EAP or AAA etc. Currently they are using normal shared-secret authentication but in most cases their shared-secrets are not really random, but some kind of human writtable words so they can be transmitted over phone, thus they are vulnerable to the off-line dictionary attacks now. There are other use cases, but for example remote access scenarios there are already EAP methods providing same features. -- kivinen@iki.fi From kivinen@iki.fi Wed Apr 13 04:45:02 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 36C5EE0751 for ; Wed, 13 Apr 2011 04:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KOLsXzzQLOo for ; Wed, 13 Apr 2011 04:45:01 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfc.amsl.com (Postfix) with ESMTP id F1399E06C2 for ; Wed, 13 Apr 2011 04:45:00 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p3DBgH6f028150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 14:42:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p3DBgGnF026838; Wed, 13 Apr 2011 14:42:16 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19877.35864.791739.535358@fireball.kivinen.iki.fi> Date: Wed, 13 Apr 2011 14:42:16 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 9 min Cc: Yoav Nir , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" , Nico Williams Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:45:02 -0000 Dan Harkins writes: > I'm a bit undecided on Tero's proposal. I tend to get in trouble when > I ascribe motivation to things people do so I won't do that, but as > someone who actually implements the protocols we design here I think > having n protocols, where n > 1, to solve a single problem with no clear > "winner" means that for interoperability reasons I have to implement > all n and that's a shame. Since Tero actually implements these protocols > too I think he might share that concern. Yes. I will most likely need to implement all of the protocols, and as I am programmer, I am by defination lazy. And as I am lazy that means I want to make my job as easy as possible. Currently all 4 methods use different methods to negotiate which method is used, uses different payload format, uses different exchange types, and uses different ways for calculating the AUTH payloads. There are some fundamental differences in the protocols, for example the way they calculate the AUTH payloads, which we cannot solve with common code, but the agreement which method to use, exchange types, payload formats etc are something which share lots of stuff and I do not want to write the same stuff 4 times, I want to write it once, so I want to make them same... > It might be possible to get the authors of the competing drafts to > rely on a common method of identifying the intent of the initiator > (currently PACE uses a Notify and SPSK uses the mandatory bit) and That was my step 1. > ensure that their protocols all look the same-- send a blob, get a blob, > send another blob, get another blob-- As far as I can read the drafts they already all do the that in the same way. > and to mix results from PAKE exchange into results of the D-H > exchange in a uniform manner And this is something all of them most likely will do differently, so I have no high hopes of having one way to do that, so most likely this code needs to be written 4 times... > and we might get the equivalent of what he's proposing without Yet > Another Pluggable Architecture (which I guess we both agree would be > not-so-good). And as I said I do not want to have generic pluggable architecture, I want to have methods sharing as much common code as possible. > Now the drafts are in LC. Maybe a few comments could get the authors > to align their drafts so they look architecturally identical while > implementing different exchanges. Yes, altough I think it is easier if the common stuff is in separate document, and all others refer to that, as it makes keeping different versions in sync easier. It would be completely ok for me if all drafts just incorporated the changes to their drafts, as it would make my life even easier as then I do not need to write that draft describing the common stuff (did I mention I am lazy :-), but making sure they are aligned exactly may make things bit hard. Also implementors could not be sure that all of them are really aligned, because they do not refer to common text, meaning implementor need to check all of the documents and make sure they are aligned before they can implement them. -- kivinen@iki.fi From kivinen@iki.fi Wed Apr 13 04:49:57 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 96A13E0753 for ; Wed, 13 Apr 2011 04:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1b8FrS+wiO3 for ; Wed, 13 Apr 2011 04:49:57 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfc.amsl.com (Postfix) with ESMTP id BFC52E0749 for ; Wed, 13 Apr 2011 04:49:56 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p3DBlGTB028035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 14:47:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p3DBlG1t027922; Wed, 13 Apr 2011 14:47:16 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19877.36164.264838.401089@fireball.kivinen.iki.fi> Date: Wed, 13 Apr 2011 14:47:16 +0300 From: Tero Kivinen To: Nico Williams In-Reply-To: References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: Yoav Nir , Dan Harkins , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:49:57 -0000 Nico Williams writes: > I fail to see how Tero's proposal makes any headway. Customers who > have and want to use AAA will not be able to use it, near as I can > tell, and if you undertake to make it possible to use AAA in Tero's > proposal then you'll be quickly approximating EAP re-invention. If you want to use AAA, you use EAP. We already have EAP in the IKEv2, there is no need for another method which supports AAA than that. We also have mutual EAP authentication as extension and we do have some of those same secure password authentication methods proposed as EAP methods too. > Which I-Ds are in last call?? http://datatracker.ietf.org/doc/draft-harkins-ipsecme-spsk-auth/ http://datatracker.ietf.org/doc/draft-kuegler-ipsecme-pace-ikev2/ http://datatracker.ietf.org/doc/draft-shin-augmented-pake/ and then there are one more which is not yet there: http://datatracker.ietf.org/doc/draft-sheffer-ipsecme-hush/ and then we have the selection criteria document for background information: http://datatracker.ietf.org/doc/draft-harkins-ipsecme-pake-criteria/ -- kivinen@iki.fi From kivinen@iki.fi Wed Apr 13 04:56:45 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E7978E0749 for ; Wed, 13 Apr 2011 04:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZCRhHyay5Rl for ; Wed, 13 Apr 2011 04:56:45 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfc.amsl.com (Postfix) with ESMTP id 12D12E0682 for ; Wed, 13 Apr 2011 04:56:44 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p3DBuWYM026949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 14:56:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p3DBuWT4002272; Wed, 13 Apr 2011 14:56:32 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19877.36720.667121.699156@fireball.kivinen.iki.fi> Date: Wed, 13 Apr 2011 14:56:32 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <4DA4B259.1050809@gmail.com> References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> <4DA4B259.1050809@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 7 min Cc: Yoav Nir , Dan Harkins , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" , Nico Williams Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:56:46 -0000 Yaron Sheffer writes: > So I don't think we need a whole framework. We just need a way for the > two peers to negotiate which method(s) they support early enough, i.e. > in IKE_SA_INIT. In PACE we use a notification, and I strongly urge the > two other documents' authors to do the same. But I'm willing to be > convinced to switch to another method if that's the group's preference. So you want exactly what my framework is. I.e. common way to negotiate the use of methods. > Other than that, I really don't see the value in uniform "meta-payloads" > and "super-notifications", or how they would simplify implementations. As an implementors all of those methods seem to use mostly similar payloads. Also I do not see any reason to use different exchange type for differnet methods, as they do not really change the way the IKE_AUTH exchange works. The meta-payloads make IKEv2 library code easier, as it just needs to implement parsing, encoding, debug printing etc only one payload. It does not need to know anything of the internals of the payload data. It will just give that to the method, which will then parse and process it further. This means that when we first implement the first mehod we need to write code to parse/generate those meta-payloads and thats it. When we add another method later we do not need to touch that part of code at all, we just add the method specific parsing in the library doing that stuff. The payloads coming out from the IKEv2 require all kind of generic checking that can be shared between these similar payloads, but if each of them is implemented as separate payload type, then it needs to be duplicated. The super-notification is simply just way to make sure the IKE_SA_INIT packet stays small enough. We do not want to add too many notification payloads there. On the other hand as we do make OEM toolkit, I do see that we for example most likely will be implementing multiple of those methods, which means that it is important for us that those methods can easily co-exists in the same implementation. -- kivinen@iki.fi From yaronf.ietf@gmail.com Wed Apr 13 05:40:50 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 594B3E077A for ; Wed, 13 Apr 2011 05:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkhCJT2y1bI3 for ; Wed, 13 Apr 2011 05:40:49 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 3057AE076F for ; Wed, 13 Apr 2011 05:40:49 -0700 (PDT) Received: by wyb29 with SMTP id 29so515474wyb.31 for ; Wed, 13 Apr 2011 05:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+ex/aDkvuySqiOtjutTmi+oT4Of7PGobw5N4tA2PXGM=; b=lnuw0CbT5PCuWT4APdp4/U8VnVxkZW/cSpxuMCeXLJ6aoTHnkP8t94veYFyyJBJh6B V66NCUXJQa83HcRmDEFYKar6SlO+5G0rqoAz5mUQAyS73o1ALCc25GL+zSapVvMvAZtL u+y7kSVx4J6gePJfdk2S/sZIfsjc9/XV5XBCo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=EcsJgXDMtLH0sb7MW2FL/N4sZvpAqEZdpbv2CqqR2tpJ4GE7IlnW6AEEBUyb0JN0uj l7mGhdD+R7RJLFM9AbLAU1+NxJAlZjuxglP5fQPRKvGNX1Tpk35eb1EC+76rPiuUIKEl St+OmK7Og7o+W/PdYcjdVPcmCHqYgTipea01Y= Received: by 10.227.173.4 with SMTP id n4mr7950897wbz.132.1302698448405; Wed, 13 Apr 2011 05:40:48 -0700 (PDT) Received: from [10.0.0.5] (46-116-74-16.bb.netvision.net.il [46.116.74.16]) by mx.google.com with ESMTPS id b20sm315913wbb.50.2011.04.13.05.40.46 (version=SSLv3 cipher=OTHER); Wed, 13 Apr 2011 05:40:47 -0700 (PDT) Message-ID: <4DA599CC.9070100@gmail.com> Date: Wed, 13 Apr 2011 15:40:44 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Tero Kivinen References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> <58f7a83f2bc1aceebc511ef896e1ae5f.squirrel@www.trepanning.net> <19877.36164.264838.401089@fireball.kivinen.iki.fi> In-Reply-To: <19877.36164.264838.401089@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Yoav Nir , Dan Harkins , "ipsec@ietf.org" , "seonghan.shin@aist.go.jp" , "sfluhrer@cisco.com" , "dennis.kuegler@bsi.bund.de" , Nico Williams Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 12:40:50 -0000 Hi Tero, To clarify (once again): I am NOT moving forward with HUSH. I think it's a nice contribution and I'm not aware of any major problems with it, but I'd rather concentrate on one PAKE method. I decided to go with PACE for the sole reason that it comes with a security proof. Thanks, Yaron On 04/13/2011 02:47 PM, Tero Kivinen wrote: > Nico Williams writes: >> I fail to see how Tero's proposal makes any headway. Customers who >> have and want to use AAA will not be able to use it, near as I can >> tell, and if you undertake to make it possible to use AAA in Tero's >> proposal then you'll be quickly approximating EAP re-invention. > > If you want to use AAA, you use EAP. > > We already have EAP in the IKEv2, there is no need for another method > which supports AAA than that. We also have mutual EAP authentication > as extension and we do have some of those same secure password > authentication methods proposed as EAP methods too. > >> Which I-Ds are in last call?? > > http://datatracker.ietf.org/doc/draft-harkins-ipsecme-spsk-auth/ > http://datatracker.ietf.org/doc/draft-kuegler-ipsecme-pace-ikev2/ > http://datatracker.ietf.org/doc/draft-shin-augmented-pake/ > > and then there are one more which is not yet there: > > http://datatracker.ietf.org/doc/draft-sheffer-ipsecme-hush/ > > and then we have the selection criteria document for background > information: > > http://datatracker.ietf.org/doc/draft-harkins-ipsecme-pake-criteria/ From nico@cryptonector.com Wed Apr 13 09:59:09 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1A6F2E07B9 for ; Wed, 13 Apr 2011 09:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkeBjA52+M3T for ; Wed, 13 Apr 2011 09:59:08 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfc.amsl.com (Postfix) with ESMTP id F391BE079F for ; Wed, 13 Apr 2011 09:59:07 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id E8C5C54077 for ; Wed, 13 Apr 2011 09:59:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=CIJOoRrZOIgzhYyr7UqcF 5MOx/rfojxYuBJgKSFNb286mvxKoXs96OHlxwH7qfWH8zP0iFm33cLUtVkh5SHpw 2jtCEMHQRwlDmMIb78VEyIILBtMPK9HLMqsvVmNtrNrNUwuRlXzD1XY4ErKwtOXl fQ2UY94l5Dx4RoKRMS72X0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=U+vOujT+DbJoD2A/HTtU CeXez7U=; b=RGimQcH07qwET5kDBvZjlZ3RBMnfo7CbO/qjm93QmpVA63Gd1pZL s3NEqDMd3Wceww7zVxMqhhkCy8lQstzcwox4YzgIE03K1fUy/4A8NPc9cXrVkoAg u61rES1WZVHjOwMmEjqJhXJk/DpFSMd0hJ1Oc6zbC04cBIzpYK+527A= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id BE8FE54057 for ; Wed, 13 Apr 2011 09:59:06 -0700 (PDT) Received: by vws12 with SMTP id 12so775941vws.31 for ; Wed, 13 Apr 2011 09:59:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.92.38 with SMTP id cj6mr4170288vdb.254.1302713945926; Wed, 13 Apr 2011 09:59:05 -0700 (PDT) Received: by 10.52.163.228 with HTTP; Wed, 13 Apr 2011 09:59:05 -0700 (PDT) In-Reply-To: <19877.32916.912580.889246@fireball.kivinen.iki.fi> References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> <19877.32916.912580.889246@fireball.kivinen.iki.fi> Date: Wed, 13 Apr 2011 11:59:05 -0500 Message-ID: From: Nico Williams To: Tero Kivinen Content-Type: text/plain; charset=UTF-8 Cc: ipsec@ietf.org, dennis.kuegler@bsi.bund.de, dharkins@arubanetworks.com, seonghan.shin@aist.go.jp, sfluhrer@cisco.com Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:59:09 -0000 On Wed, Apr 13, 2011 at 5:53 AM, Tero Kivinen wrote: > Nico Williams writes: >> b) there are reserved numbers for using the GSS-API in IKEv1, and we >> could make it usable in IKEv2, > > If I remember right GSS-API is also asymmetric meaning only there is > clear separation of client and server side, and usually you cannot > assume that if I can act as GSS-API client side and connect to the > server the implementation can also act as GSS-API server side. > > I might be wrong on that issue, as I do not know GSS-API that well. I believe you are wrong about that. Evidence: SCRAM (RFC5802). If you look at SCRAM you'll see that it's exceedingly simple -- it's a pre-shared password type mechanism, loosely resembling DIGEST-MD5. All the GSS aspects of SCRAM are segregated into a small, clean section. You'd mostly not have to concern yourself with it because I volunteer to write that for you :) > Also getting all those 4 secure password authentication methods > convereted to GSS-API methods is going to require quite a lot of work, Not at all (see above). I volunteer to do the GSS bits so you don't have to. The only change I need you to make for this is to agree to let the mechanism's sub-messages carry the initiator and responder names. I can even give up on how you name the mechanisms (8-bits? fine, so you'll have an IANA registry). > and also binding GSS-API authentication to the IKEv2 authentication > also requires work. For strong mechanisms you just key the IKE_SA from output of the mechanism. All we need is for the mechanism to output key material and a PRF (which can be effectively the same as IKE's PRF, so nothing new for you). For weaker mechanisms (like SCRAM) we'd want to do a KE before running the mechanism and channel binding to the KE. This is quite simple to do: just derive a nonce-like value from the KE output (i.e., use the PRF) and then use that in the mechanism as an input on both sides -- it only needs to match on both sides. You don't even have to think of this as channel binding if you don't want to. The reason I want this is so I can reuse your mechanisms outside IKE. I'm particularly interested in using them in SSHv2 and Kerberos pre-authentication. If your mechanisms' specification is easily reusable and we can make it cheap for them to be easily reusable, we all win. That's the bargain I'm offering you. I do the work you don't want to do and I make it so you don't even have to notice that your mechanisms are actually GSS mechanisms. :) All I need is for the mechanism messages to carry the initiator and responder names, for strong mechanisms to output a PRF and seed, and for weak mechanisms to do channel binding (which is trivial). Deal? Nico -- From VSasi@ixiacom.com Wed Apr 13 20:57:18 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 74374E06D3 for ; Wed, 13 Apr 2011 20:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.69 X-Spam-Level: X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5vdCpLAGfyo for ; Wed, 13 Apr 2011 20:57:07 -0700 (PDT) Received: from ixqw-mail-out.ixiacom.com (ixqw-mail-out.ixiacom.com [66.77.12.12]) by ietfc.amsl.com (Postfix) with ESMTP id 7AF6EE0707 for ; Wed, 13 Apr 2011 20:57:07 -0700 (PDT) Received: from ixcaexch07.ixiacom.com ([fe80:0000:0000:0000:e021:fcf5:238.143.231.20]) by ixqw-hc1.ixiacom.com ([10.210.5.15]) with mapi; Wed, 13 Apr 2011 20:57:06 -0700 From: Vinod Sasi To: "'Scott Fluhrer (sfluhrer)'" , "ipsec@ietf.org" Date: Wed, 13 Apr 2011 20:57:06 -0700 Thread-Topic: [IPsec] Queries relating to ESP/AH GCM & GMAC Thread-Index: AcvznEI7HgmLeLnIR0OYbicIGlj+mgAB5wdgAB+tzAAAEWV5kAF7UUXg Message-ID: <716209EC190CA740BA799AC4ACCBFB5D1851CEE71D@IXCAEXCH07.ixiacom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_716209EC190CA740BA799AC4ACCBFB5D1851CEE71DIXCAEXCH07ixi_" MIME-Version: 1.0 Subject: Re: [IPsec] Queries relating to ESP/AH GCM & GMAC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 03:57:18 -0000 --_000_716209EC190CA740BA799AC4ACCBFB5D1851CEE71DIXCAEXCH07ixi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Scott, Thank you for your time. To give you a background, I am implementing a conf= ormance tool which exercises GCM/GMAC using ESP/AH for IKev1, running again= st Strongswan. Based on your inputs, I have been able to successfully negot= iate ikev1 & send ESP/GCM packets using IKEv1 to Strongswan. Now I am onto AH GMAC, I have few more clarification based on your reply no= w. [scott] "For AH GMAC, the IV is part of a mutable section, so either order = would work." 1.) Since you have mentioned IV as mutable, it should be ideally be zer= oed before being sent. But in the first place should I be including the IV = in the AAD input or actual payload for AH? I am clear on the ESP GMAC part. 2.) IV should be prepended to ICV tag manually before being sent over t= he wire & I wouldn't expect the algorithm to do this step. 3.) The GMAC receiver inspects the IV & feeds it to the algorithm to co= mpute the ICV. [scott] "A general purpose GCM (the cryptographical algorithm) implementati= on should be able to perform the computations for the ESP GCM, ESP GMAC and= AH GMAC IPsec transforms; however, the AAD and plaintext/ciphertext inputs= would differ." I am using the Libtomcrypt library which implements the GCM, I am customizi= ng the same for GMAC & I hope it works!!! Rgds, Vinod -----Original Message----- From: Scott Fluhrer (sfluhrer) [mailto:sfluhrer@cisco.com] Sent: Wednesday, April 06, 2011 8:33 PM To: Vinod Sasi; ipsec@ietf.org Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC From: Vinod Sasi [mailto:VSasi@ixiacom.com] Sent: Wednesday, April 06, 2011 2:43 AM To: Scott Fluhrer (sfluhrer); ipsec@ietf.org Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC Hello Scott, Many thanks for your reply; this is helping me to a great extent. Few more clarifications from your reply.. 1.) RFC 4106 talks about Nonce =3D IV + Salt (last 4 bytes of keying materi= al derived during SA creation). But where do we actually use it in the cont= ext of ESP & AH? I derive the 8-byte IV, feed those 8-bytes as input to th= e GCM Algorithm, take the cipher out & prepend it with the same 8-byte IV b= efore sending it out on the wire. You feed the 12 byte nonce as input to the GCM algorithm, not the 8 byte IV= . 2.) Between ESP GMAC & AH GMAC. Please confirm my understanding. a. Plain_text=3DZero for both By zero, I assume you mean the empty string. b. AAD constructed accordingly for ESP & AH outlined in RFC 4303 & 43= 02 c. 8-byte IV is fed to GMAC algorithm for ESP & AH. 12 byte nonce. d. Before being sent over the wire, for ESP the IV is prepended with = the actually payload (IP/TCP/UDP). For AH the IV is prepended with the ICV = tag. Actually, for ESP GMAC, this step needs to happen before (b), because the I= V is included in the AAD (the region being authenticated). For AH GMAC, t= he IV is part of a mutable section, so either order would work. e. Both have fixed ICV lengths Yes, that is correct. Now, the ESP-GCM transform does have variable ICV le= ngths (8, 12, 16 octets); I'd strongly advise everyone to use the 16 octet = length; there are known security problems if you truncate the ICV. 3.) Between GCM & GMAC algorithm, only difference being for GMAC the pl= ain_text=3Dzero. No, another difference is that the AAD are constructed differently. So technically a GCM Algorithm code will act as GMAC is my actually payload= length provided as input is zero. A general purpose GCM (the cryptographical algorithm) implementation should= be able to perform the computations for the ESP GCM, ESP GMAC and AH GMAC = IPsec transforms; however, the AAD and plaintext/ciphertext inputs would di= ffer. Thanks in advance, Vinod -----Original Message----- From: Scott Fluhrer (sfluhrer) [mailto:sfluhrer@cisco.com] Sent: Tuesday, April 05, 2011 9:30 PM To: Vinod Sasi; ipsec@ietf.org Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC Importance: Low From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of V= inod Sasi Sent: Tuesday, April 05, 2011 10:18 AM To: 'ipsec@ietf.org' Subject: [IPsec] Queries relating to ESP/AH GCM & GMAC Hello, I have been reading RFC 4106 & 4543 over the past 2 weeks & in the process = of implementing this RFC for IKEv1 module for my customer. There is a long pending clarification, Appreciate your help on establishing= clarity. 1. What is the scope of Authentication between ESP GMAC & AH GMAC? Shall = I use the understanding outlined in RFC 2401 Section 4.2 Pg 9? I'd use the more detailed descriptions in RFC 4303 and 4302; they define ex= actly what fields are included in the integrity check and (for AH) which fi= elds are considered 'mutable' (and are implicitly replaced by zeros for the= purposes of doing the integrity check). 2. What is the IV mode for GCM & GMAC? How to establish IV synchronizatio= n between the sender & receiver. For (e.g.) AES the IV is placed as the fir= st 16-byte block before Cipher text & sent over the wire. Do I follow the s= ame for GCM/GMAC? It's explained in RFC 4106; the encryptor picks an 8 byte IV, and includes = it in the packet; the decryptor extracts this 8 byte IV from the packet. N= ote that the GCM/GMAC nonce is actually 12 bytes; 8 bytes come from the IV,= and the other 4 bytes come from the keying material ("salt"). Also, important note (RFC 4106 mentions it; it's important enough for me to= reiterate it); it's critical that you never generate two packets with the = same IV (for the same GCM/GMAC key). GCM IVs are not the same as CBC-mode = IVs. With CBC mode, what's important is that the IV be unpredictable (and = so, say, using a random number generator to pick CBC-mode IVs is a good sol= ution). With GCM, it doesn't matter in the slightest if the IV is unpredic= table; what's important is that they never repeat. Randomly picking GCM mo= de IVs will mean that you'll likely to get a repeat after a few billion pac= kets; that'd be bad. Instead, one good way of picking the IVs is to use a c= ounter (you could even reuse the IPSec sequence number if your implementati= on makes that convenient). Some other subtle points: - ESP GMAC is technically a 'combined mode'; what this means is that, = as far as IPSec is concerned, it's both an encryption algorithm and an auth= entication algorithm. It doesn't actually provide confidentiality, but it = is considered an encryption algorithm in the same way that ESP NULL is. On= e implication of that is that it can't be used with, say, ESP AES CBC (just= like you can't use both ESP AES CBC and ESP NULL in the same SA). If you = want both confidentially and integrity, use either ESP-GCM, or AH GMAC and = your favorite ESP encryption algorithm. - AH GMAC and IPv6 has a glitch which I don't think are mentioned expl= icitly in the RFCs; AH is an 'extension header' within IPv6, and the IPv6 R= FC (2460, see section 4) must be a multiple of 8 octets in length. However= , a straight-forward implementation of the AH header with RFC 4543 would yi= eld a 28 octet header (12 octets for the next header/payload length/SPI/seq= no, and 16 octets for the ICV value); 28 is not a multiple of 8. What you = need to do (if you're serious about following the IPv6 RFC) is include an a= dditional 4 octets after the ICV if you're using IPv6. I'd make those 4 oc= tets all zeros; that way, you don't have to worry whether the other side co= nsiders them mutable or not. Thanks in advance, Vinod --_000_716209EC190CA740BA799AC4ACCBFB5D1851CEE71DIXCAEXCH07ixi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Scott,

 

Thank you for your time. To give you a background, I am implementing a conformance tool which exercises GCM/GMAC u= sing ESP/AH for IKev1, running against Strongswan. Based on your inputs, I have been able to successfully negotiate ikev1 & send ESP/GCM packets using IKEv1 to Strongswan.

 

Now I am onto AH GMAC, I have few more clarification based on your reply now.

 

[scott] “For AH GMAC, the IV is part of a mutable section, so either or= der would work.”

1.)     Since you have ment= ioned IV as mutable, it should be ideally be zeroed before being sent. But in the= first place should I be including the IV in the AAD input or actual payload for A= H? I am clear on the ESP GMAC part.

2.)     IV should be prepen= ded to ICV tag manually before being sent over the wire & I wouldn’t exp= ect the algorithm to do this step.

3.)     The GMAC receiver inspects the IV & feeds it to the algorithm to compute the ICV.<= /font>

 

 

[scott] “A general purpose GCM (the cryptographical algorithm) implementation should be able to perform the computations for the ESP GCM, = ESP GMAC and AH GMAC IPsec transforms; however, the AAD and plaintext/ciphertex= t inputs would differ.”

I am using the Libtomcrypt library whi= ch implements the GCM, I am customizing the same for GMAC & I hope it work= s!!!

 

Rgds,

Vinod

 

 

-----Original Message----- From: Scott Fluhrer (sfluhre= r) [mailto:sfluhrer@cisco.com]
Sent: Wednesday, April 06, 2= 011 8:33 PM
To: Vinod Sasi; ipsec@ietf.o= rg
Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC

 

 

 

From:= = Vinod Sasi [mailto:VSasi@ixiacom.com]
Sent: Wednesday, April 06, 2= 011 2:43 AM
To: Scott Fluhrer (sfluhrer)= ; ipsec@ietf.org
Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC

 

Hello Scott,=

 

Many thanks for you= r reply; this is helping me to a great extent.

 

Few more clarificat= ions from your reply..

= 1.) RFC 4106 talks abou= t Nonce =3D IV + Salt (last 4 bytes of keying material derived during SA crea= tion). But where do we actually use it in the context of ESP & AH?  I der= ive the 8-byte IV, feed those 8-bytes as input to the GCM Algorithm, take the cipher out & prepend it with the same 8-byte IV before sending it out o= n the wire.

You feed the 12 byte nonce as input to the GCM algorithm, not the 8 byte IV.

  =

=  

2.)     Between ESP GMAC & AH GMAC. Please confirm my understanding= .

a.       Plain_text=3DZero for both

By zero, I assume you mean the empty string.

 

b.       AAD constructed accordingly for ESP & AH outlined in RFC 43= 03 & 4302

c.       8-byte IV is fed to GMAC algorithm for ESP & AH.

12 byte nonce.

 

d.       Before being sent over the wire, for ESP the IV is prepended wi= th the actually payload (IP/TCP/UDP). For AH the IV is prepended with the ICV = tag.

Actually, for ESP GMAC, this step needs to happen before (b), because the IV is inclu= ded in the AAD (the region being authenticated).   For AH GMAC, the I= V is part of a mutable section, so either order would work.

 

e.       Both have fixed ICV lengths

Yes, that is correct.  Now, the ESP-GCM transform does have variable ICV lengths (8, 12, 16 octets); I’d strongly advise everyone to use the 1= 6 octet length; there are known security problems if you truncate the ICV.

=  

3.)     Between GCM & GMAC algorithm, only difference being for GMA= C the plain_text=3Dzero.<= /p>

No, another difference is that the AAD are constructed differently.

 

So technically a GCM Algorithm code will act as GMAC is my actu= ally payload length provided as input is zero.

A general purpose GCM (the cryptographical algorithm) implementation should b= e able to perform the computations for the ESP GCM, ESP GMAC and AH GMAC IPse= c transforms; however, the AAD and plaintext/ciphertext inputs would differ.<= /span>

 

=  

Thanks in advance,<= /span>

Vinod=

 

-----Original Message----- From: Scott Fluhrer (sfluhre= r) [mailto:sfluhrer@cisco.com]
Sent: Tuesday, April 05, 201= 1 9:30 PM
To: Vinod Sasi; ipsec@ietf.o= rg
Subject: RE: [IPsec] Queries relating to ESP/AH GCM & GMAC
Importance: Low

 

 

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Vinod Sasi
Sent: Tuesday, April 05, 201= 1 10:18 AM
To: 'ipsec@ietf.org'
Subject: [IPsec] Queries rel= ating to ESP/AH GCM & GMAC

 

= Hello,

=  

= I have been reading RFC 4106 & 4543 over the past 2 weeks & in the process= of implementing this RFC for IKEv1 module for my customer.

=  

= There is a long pending clarification, Appreciate your help on establishing clarity.=

=  

1. &nbs= p; What is the scope of Authentication between ESP GMAC & AH G= MAC? Shall I use the understanding outlined in RFC 2401 Section 4.2 Pg 9?=

I’d use the more detailed descriptions in RFC 4303 and 4302; they define exactl= y what fields are included in the integrity check and (for AH) which fields a= re considered ‘mutable’ (and are implicitly replaced by zeros for = the purposes of doing the integrity check).

 

 

2. &nbs= p; What is the IV mode for GCM & GMAC? How to establish IV synchronization between the sender & receiver. For (e.g.) AES the IV is placed as the first 16-byte block before Cipher text & sent over the wi= re. Do I follow the same for GCM/GMAC?

It’s explained in RFC 4106; the encryptor picks an 8 byte IV, and includes it in= the packet; the decryptor extracts this 8 byte IV from the packet.  Note t= hat the GCM/GMAC nonce is actually 12 bytes; 8 bytes come from the IV, and the other 4 bytes come from the keying material (“salt”).

 

Also, important note (RFC 4106 mentions it; it’s important enough for me to reiterate it); it’s critical that you never generate two packets with= the same IV (for the same GCM/GMAC key).  GCM IVs are not the same as CBC-= mode IVs.  With CBC mode, what’s important is that the IV be unpredictable (and so, say, using a random number generator to pick CBC-mod= e IVs is a good solution).  With GCM, it doesn’t matter in the slightest if the IV is unpredictable; what’s important is that they n= ever repeat.  Randomly picking GCM mode IVs will mean that you’ll lik= ely to get a repeat after a few billion packets; that’d be bad. Instead, = one good way of picking the IVs is to use a counter (you could even reuse the I= PSec sequence number if your implementation makes that convenient).

 

 

Some other subtle points:

= -      ESP GMAC is technically a ‘combined mode’; what th= is means is that, as far as IPSec is concerned, it’s both an encryption algorithm and an authentication algorithm.  It doesn’t actually provide confidentiality, but it is considered an encryption algorithm in th= e same way that ESP NULL is.  One implication of that is that it canR= 17;t be used with, say, ESP AES CBC (just like you can’t use both ESP AES = CBC and ESP NULL in the same SA).  If you want both confidentially and integrity, use either ESP-GCM, or AH GMAC and your favorite ESP encryption algorithm.

= -      AH GMAC and IPv6 has a glitch which I don’t think are mentioned explicitly in the RFCs; AH is an ‘extension header’ within IPv6, and the IPv6 RFC (2460, see section 4) must be a multiple of 8 octets in length.  However, a straight-forward implementation of the A= H header with RFC 4543 would yield a 28 octet header (12 octets for the next header/payload length/SPI/seqno, and 16 octets for the ICV value); 28 is no= t a multiple of 8.  What you need to do (if you’re serious about following the IPv6 RFC) is include an additional 4 octets after the ICV if you’re using IPv6.  I’d make those 4 octets all zeros; tha= t way, you don’t have to worry whether the other side considers them mutable or not.

 

=  

= Thanks in advance,

= Vinod

 

--_000_716209EC190CA740BA799AC4ACCBFB5D1851CEE71DIXCAEXCH07ixi_-- From kivinen@iki.fi Fri Apr 15 03:06:57 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AC0D1E0676 for ; Fri, 15 Apr 2011 03:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE8SIjvanz2E for ; Fri, 15 Apr 2011 03:06:56 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfc.amsl.com (Postfix) with ESMTP id 92842E065A for ; Fri, 15 Apr 2011 03:06:56 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p3FA6QCE017218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2011 13:06:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p3FA6N8O022493; Fri, 15 Apr 2011 13:06:23 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19880.6303.383829.951731@fireball.kivinen.iki.fi> Date: Fri, 15 Apr 2011 13:06:23 +0300 From: Tero Kivinen To: Nico Williams In-Reply-To: References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> <19877.32916.912580.889246@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 14 min Cc: ipsec@ietf.org, dennis.kuegler@bsi.bund.de, dharkins@arubanetworks.com, seonghan.shin@aist.go.jp, sfluhrer@cisco.com Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 10:06:57 -0000 Nico Williams writes: > I believe you are wrong about that. Evidence: SCRAM (RFC5802). > > If you look at SCRAM you'll see that it's exceedingly simple -- it's a > pre-shared password type mechanism, loosely resembling DIGEST-MD5. I have not yet read the SCRAM, but based on the discussion on the secdir list, I think you were missing some points of this discussion in here too. All of these 3 (hush is withdrawn as pointed out to me) methods we are discussing here are ZKPP. IPsecME charter says: ---------------------------------------------------------------------- - IKEv2 supports mutual authentication with a shared secret, but this mechanism is intended for "strong" shared secrets. User-chosen passwords are typically of low entropy and subject to off-line dictionary attacks when used with this mechanism. Thus, RFC 4306 recommends using EAP with public-key based authentication of the responder instead. This approach would be typically used in enterprise remote access VPN scenarios where the VPN gateway does not usually even have the actual passwords for all users, but instead typically communicates with a back-end RADIUS server. However, user-configured shared secrets are still useful for many other IPsec scenarios, such as authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either peer can initiate an IKEv2 SA. While it would be possible to use EAP in such situations (by having both peers implement both the EAP peer and the EAP server roles of an EAP method intended for "weak" shared secrets) with the mutual EAP-based authentication work item (above), a simpler solution may be desirable in many situations. The WG will develop a standards-track extension to IKEv2 to allow mutual authentication based on "weak" (low-entropy) shared secrets. The goal is to avoid off-line dictionary attacks without requiring the use of certificates or EAP. There are many already-developed algorithms that can be used, and the WG would need to pick one that both is believed to be secure and is believed to have acceptable intellectual property features. The WG would also need to develop the protocol to use the chosen algorithm in IKEv2 in a secure fashion. It is noted up front that this work item poses a higher chance of failing to be completed than other WG work items; this is balanced by the very high expected value of the extension if it is standardized and deployed. ---------------------------------------------------------------------- So the major points are: - Machine to machine communication (i.e. no user) - Weak password created by admins and entered to the configs - Symmetric nature, i.e. either end can initiate communications, there is no server and client roles - Needs to be secure against off-line dictionary attacks even against active attackers - No certificate support required - No AAA infrastructure required > All the GSS aspects of SCRAM are segregated into a small, clean > section. You'd mostly not have to concern yourself with it because I > volunteer to write that for you :) If I understood your comments in the secdir list correctly SCRAM does not fill all of those requirements? -- kivinen@iki.fi From nico@cryptonector.com Fri Apr 15 12:09:28 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ACE52E0798 for ; Fri, 15 Apr 2011 12:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4XCqiQZCy21 for ; Fri, 15 Apr 2011 12:09:28 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfc.amsl.com (Postfix) with ESMTP id CE5CCE0774 for ; Fri, 15 Apr 2011 12:09:27 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id F120AB805B for ; Fri, 15 Apr 2011 12:09:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=NxBjvJ7Jb9jdiIAqSX8vzwmSKcKfwK1Fi9leOcQBeyuS u60Z2WcUd68T5Do6TDtvhx+LC10JpNa0Yuf4hb8eyubX905FXRRAVQmvgX6nO+xN 9NZKcEOZi+p6VRP9lYjSSmyn1IGnM7Pr1pJio2z+bI8RLq4KGWrFR+aizfGjF/U= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=s7UGvauwQvDIQH4w+mCJVM1SCx8=; b=sOGeJRSIdJz jMnvig9HnIWhh1J/T7i6CmGeV0V54Lt/ZOvRjBm9OM389dHHRDfpu6B01cv6/ZTF DfkuKcuSJAH1M+B1/1IwlS5dLf5qapXgP+aQmdFsRiw/NOHQyzi35oELpSHvwLFj O2bK9OHdC9X9uLseyfx9QWzQIFCtE/Ak= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id C5982B8058 for ; Fri, 15 Apr 2011 12:09:26 -0700 (PDT) Received: by vxg33 with SMTP id 33so2889018vxg.31 for ; Fri, 15 Apr 2011 12:09:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.74.36 with SMTP id q4mr2157719vdv.134.1302894566105; Fri, 15 Apr 2011 12:09:26 -0700 (PDT) Received: by 10.52.163.228 with HTTP; Fri, 15 Apr 2011 12:09:26 -0700 (PDT) In-Reply-To: <19876.17130.712471.646073@fireball.kivinen.iki.fi> References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> Date: Fri, 15 Apr 2011 14:09:26 -0500 Message-ID: From: Nico Williams To: Tero Kivinen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Cc: ipsec@ietf.org, dennis.kuegler@bsi.bund.de, dharkins@arubanetworks.com, seonghan.shin@aist.go.jp, sfluhrer@cisco.com Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 19:09:28 -0000 T24gVHVlLCBBcHIgMTIsIDIwMTEgYXQgNzoxNyBBTSwgVGVybyBLaXZpbmVuIDxraXZpbmVuQGlr aS5maT4gd3JvdGU6Cj4gMykgVGhlIElLRV9TQV9JTklUIGFuZCBJS0VfQVVUSCBhcmUgdXNlZCBh cyBleGNoYW5nZSB0eXBlcywgYnV0IHRoZQo+IMKgIGV4dHJhIHBheWxvYWRzIGluIHRoZW0gZGVw ZW5kIG9uIHRoZSBTUEFNIGFsZ29yaXRobSB1c2VkLCBhbmQgdGhlCj4gwqAgU1BBTSBhbGdvcml0 aG0gdXNlZCBhbHNvIGFmZmVjdHMgdGhlIEFVVEggcGF5bG9hZCBnZW5lcmF0aW9uLiBUaGUKPiDC oCBleGNoYW5nZSB3aWxsIHNpbWlsYXIgdG8gRUFQLCBpLmUuOgo+Cj4gwqAgSW5pdGlhdG9yIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFJlc3BvbmRlcgo+IMKgIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KPiDCoCBIRFIsIFNBaTEsIEtFaSwgTmksCj4gwqAgwqAgwqAgwqBOKFNQQU1fTUVUSE9EUykg LS0+Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqA8LS0g wqBIRFIsIFNBcjEsIEtFciwgTnIsIFtDRVJUUkVRXSwKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoE4oU1BBTV9NRVRIT0RTKQoK SWYgdGhlICJTUEFNcyIgYXJlIFpLUFBzLCB0aGV5IHN1cmVseSBvdXRwdXQga2V5IG1hdGVyaWFs LCBzbyB3aHkKYm90aGVyIHdpdGggS0VpL0tFciBoZXJlPyAgSXMgaXQgZm9yIHByaXZhY3kgcHJv dGVjdGlvbiBvZiB0aGUgSUQKcGF5bG9hZHMgYmVsb3c/Cgo+IMKgIEhEUiwgU0sge0lEaSwgW0NF UlRSRVEsXQo+IMKgIMKgIMKgIFNQQU1fUEFZTE9BRCwKPiDCoCDCoCDCoCBTUEFNX1BBWUxPQUQs IC4uLgo+IMKgIMKgIMKgIFtJRHIsXSBTQWkyLAo+IMKgIMKgIMKgIFRTaSwgVFNyfSDCoC0tPgo+ IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgPC0tIMKgSERS LCBTSyB7SURyLCBbQ0VSVCxdCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU1BBTV9QQVlMT0FELAo+IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNQQU1fUEFZTE9BRCwg Li4uIH0KPiDCoCBIRFIsIFNLIHtTUEFNX1BBWUxPQUQsIC4uLn0gwqAtLT4KPiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDwtLSDCoEhEUiwgU0sge1NQQU1f UEFZTE9BRCwgLi4ufQo+IMKgIEhEUiwgU0sge1tTUEFNX1BBWUxPQUQsIC4uLl0sCj4gwqAgwqAg wqAgwqAgwqAgwqBBVVRIfSDCoC0tPgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgPC0tIMKgSERSLCBTSyB7W1NQQU1fUEFZTE9BRCwgLi4uXSwKPiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoEFVVEgsIFNBcjIsIFRTaSwgVFNyIH0KClN0dWR5aW5nIHRoaXMgbW9yZSBjYXJlZnVs bHksIEkgdGhpbmsgdGhpcyBpcyBjbG9zZSB0byBmdWxseQpnZW5lcmFsaXphYmxlIC0tIGluIGEg d2F5IHdoZXJlIEkgY291bGQgYm9ycm93IHRoZSBzcGVjIHRvIG1ha2UgR1NTCm1lY2hzIG91dCBv ZiB0aGlzIGluc3RlYWQgb2YgdGhlIG90aGVyIHdheSBhcm91bmQuICBUaGUgb25seSB0aGluZ3MK bWlzc2luZyAoY2hhbm5lbCBiaW5kaW5nLCBnZW5lcmljIElEIHBheWxvYWRzLCBHU1MgZmxhZ3Mg Y29udmV5YW5jZSkKY291bGQgYmUgYWRkZWQgc2VwYXJhdGVseS4gIEFsc28sIEknZCB3YW50IHRv IHZlcnkgY2xlYW5seSBzZXBhcmF0ZQp0aGUgIlNQQU0iIG5lZ290aWF0aW9uIGZyb20gdGhlICJT UEFNIiBtZXNzYWdlcy4gIChEaWQgSSBtZW50aW9uIHRoYXQKU1BBTSBpcyBhIHRyYWRlbWFyaz8g OikKCkknbGwgdGhpbmsgYWJvdXQgdGhpcyBzb21lIG1vcmUuCg== From kivinen@iki.fi Mon Apr 18 06:21:46 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E8C5CE0693 for ; Mon, 18 Apr 2011 06:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upDAHnCyWp78 for ; Mon, 18 Apr 2011 06:21:45 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfc.amsl.com (Postfix) with ESMTP id 49C22E0664 for ; Mon, 18 Apr 2011 06:21:44 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p3IDKupl025819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Apr 2011 16:20:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p3IDKqQp026324; Mon, 18 Apr 2011 16:20:52 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <19884.15028.391649.600542@fireball.kivinen.iki.fi> Date: Mon, 18 Apr 2011 16:20:52 +0300 From: Tero Kivinen To: Nico Williams In-Reply-To: References: <19876.17130.712471.646073@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 10 min Cc: ipsec@ietf.org, dennis.kuegler@bsi.bund.de, dharkins@arubanetworks.com, seonghan.shin@aist.go.jp, sfluhrer@cisco.com Subject: Re: [IPsec] Proposal for the secure password authentication method problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:21:47 -0000 Nico Williams writes: > On Tue, Apr 12, 2011 at 7:17 AM, Tero Kivinen wrote:= > > 3) The IKE=5FSA=5FINIT and IKE=5FAUTH are used as exchange types, b= ut the > > =A0 extra payloads in them depend on the SPAM algorithm used, and t= he > > =A0 SPAM algorithm used also affects the AUTH payload generation. T= he > > =A0 exchange will similar to EAP, i.e.: > > > > =A0 Initiator =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Respo= nder > > =A0 ---------------------------------------------------------------= ---- > > =A0 HDR, SAi1, KEi, Ni, > > =A0 =A0 =A0 =A0N(SPAM=5FMETHODS) --> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<-- = =A0HDR, SAr1, KEr, Nr, [CERTREQ], > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0N(SPAM=5FMETHODS) >=20 > If the "SPAMs" are ZKPPs, they surely output key material, so why > bother with KEi/KEr here=3F Is it for privacy protection of the ID > payloads below=3F You really need to ask that from the authors of the methods, I just took all of the methods and created common structure over them. All of them do normal IKEv2 IKE=5FSA=5FINIT before they start do anything else= =2E They all do normal IKEv2 Diffie-Hellman and create (unauthenticated) encrypted channel between the nodes and then create AUTH paload using the SignedOctets from the IKEv2 in addition to their own stuff to authenticate that channel. The good think is that they do it that way, as it means there is very little actual changes to the IKEv2 because of that. If they would create keying material needed to encrypt and mac the IKE=5FAUTH payloads, then those changes would be much bigger to the generic IKEv2 code than what now seems to be needed.=20 > > =A0 HDR, SK {IDi, [CERTREQ,] > > =A0 =A0 =A0 SPAM=5FPAYLOAD, > > =A0 =A0 =A0 SPAM=5FPAYLOAD, ... > > =A0 =A0 =A0 [IDr,] SAi2, > > =A0 =A0 =A0 TSi, TSr} =A0--> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<-- = =A0HDR, SK {IDr, [CERT,] > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 SPAM=5FPAYLOAD, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 SPAM=5FPAYLOAD, ... } > > =A0 HDR, SK {SPAM=5FPAYLOAD, ...} =A0--> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<-- = =A0HDR, SK {SPAM=5FPAYLOAD, ...} > > =A0 HDR, SK {[SPAM=5FPAYLOAD, ...], > > =A0 =A0 =A0 =A0 =A0 =A0AUTH} =A0--> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<-- = =A0HDR, SK {[SPAM=5FPAYLOAD, ...], > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0AUTH, SAr2, TSi, TSr } >=20 > Studying this more carefully, I think this is close to fully > generalizable -- in a way where I could borrow the spec to make GSS > mechs out of this instead of the other way around. The only things > missing (channel binding, generic ID payloads, GSS flags conveyance) > could be added separately. You have to remember that we do NOT want to change the standard IKEv2 parts of the protocol, i.e. SAi1, KEi, Ni, SAr1, KEr, Nr, IDi, IDr, SAi2, TSi, or TSr payloads in any way. We just want to make sure the methods can transmit their stuff with as little coding as possible. Also all of the methods use different way how to calculate the AUTH payload.=20 > Also, I'd want to very cleanly separate > the "SPAM" negotiation from the "SPAM" messages. (Did I mention that= > SPAM is a trademark=3F :) I know, and most likely will put something else in the draft if we ever get that far... I should have realized that any solution proposal to the spam problem is like opening can of worms, so I should have used some other term :-) > I'll think about this some more. --=20 kivinen@iki.fi From welterk@us.ibm.com Tue Apr 19 08:49:37 2011 Return-Path: X-Original-To: ipsec@ietfc.amsl.com Delivered-To: ipsec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8B3E6E0774 for ; Tue, 19 Apr 2011 08:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAfnzUwxrJbZ for ; Tue, 19 Apr 2011 08:49:36 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by ietfc.amsl.com (Postfix) with ESMTP id E5CADE076B for ; Tue, 19 Apr 2011 08:49:35 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3JFgdY4017661 for ; Tue, 19 Apr 2011 09:42:39 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3JFnTFJ155438 for ; Tue, 19 Apr 2011 09:49:30 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3JFnSPS011156 for ; Tue, 19 Apr 2011 09:49:29 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3JFnR41011126; Tue, 19 Apr 2011 09:49:27 -0600 In-Reply-To: References: <4D37577E.8070009@vpnc.org> <19768.18814.516107.222884@fireball.kivinen.iki.fi> To: ipsec@ietf.org, Tero Kivinen , Paul Hoffman , Yoav Nir MIME-Version: 1.0 X-KeepSent: 18DF5492:1DA04179-88257877:0054F7FC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Tue, 19 Apr 2011 08:49:25 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 04/19/2011 09:49:26, Serialize complete at 04/19/2011 09:49:26 Content-Type: multipart/alternative; boundary="=_alternative 0056ED9888257877_=" Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 15:49:37 -0000 This is a multipart message in MIME format. --=_alternative 0056ED9888257877_= Content-Type: text/plain; charset="US-ASCII" > I contacted Hugo Krawczyk, the SIGMA author, and he agreed to > evaluate the security considerations of the draft. He's busy at the > moment though so we won't be able to pick-up the thread for a couple weeks. I reviewed the draft with Hugo and he explained that it is critical to sign something fresh (as opposed to something cached as proposed in the current version of the draft) and something that binds the data to the SA should be included (e.g. the SPIs). The approach Hugo suggested was that the initiator should first send the responder the data to sign. In practice this works out to four messages. For example: 1) Host A generates some fresh data (i.e. a nonce) and sends it to host B ("here, sign my data") 2) Host B signs the fresh data from host A and sends it back ("ok, I signed your data, now you sign what I just sent") 3) Host A verifies the signature from host B, signs the data from host B and sends it back ("ok, I verified your data and signed it") 4) Host B verifies the signature from host A and responds with success or failure The original version of the draft satisfied these requirements but the current version does not. The current version of the draft takes the approach of allowing a modified IKE_AUTH exchange on the original IKE SA, subsequent to the initial exchanges, for the express purpose of reauthentication. It does not provide for signing fresh nonces. The original version of the draft used the initial exchanges to reauthenticate the IKE SA (as is normally done in IKEv2) but added a notification mechanism indicating that the new IKE SA should inherit the old child SAs, thereby eliminating the round-trips that would have been required to re-establish equivalent child SAs under the new IKE SA. Therefore, I believe the approach taken in the original version of the draft is the best way forward for eliminating the unnecessary round-trips needed to re-establish child SAs during IKEv2 reauthentication (as well as solving the other problems identified by the draft). > > > > 2. There is one point I'd still like technical input on, namely the > > > security considerations of signing the previous AUTH payload sent by the > > > host in the modified IKE_AUTH exchange (section 5 of the draft). Yoav > > > suggested this approach, it sounded fine to me, I ran it by a > couple of my > > > colleagues (Scott Moonen and David Wierbowski) who thought it sound fine > > > too so I used it in the new draft. I'd feel better if another subject > > > matter expert said, "yes, that is fine." Bonus points if the SME can > > > offer a sentence or two justifying why this mechanism is as secure as the > > > authentication operation that takes place during the initial > exchanges. It > > > would be nice to include that information in the security considerations > > > section of my draft. More specifically, RFC 5996 section 2.15 > > > "Authentication of the IKE SA" says, "It is critical to the security of > > > the exchange that each side sign the other side's nonce." Is itnecessary > > > to include nonces in the signed data in the proposed modified IKE_AUTH > > > exchange? I don't think so, but since I don't know why it was necessary > > > as part of the signed data in the initial exchanges I don't feelqualified > > > to assert that formally. > > > > In the initial authentication the signing of the IKE_SA message proofs > > that nobody has modified those packets. Note, that it does not sign > > the IKE_AUTH message, as it is protected by the Integrity Checksum > > Data field. So the signing of the message data is there just to > > provide MAC for the first packets which are not MACed normally. > > > > The real authentication happens when node signs the other ends nonce > > and his own MACed ID. > > > > Read the SIGMA documentation for more details: > > > > [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to > > Authenticated Diffie-Hellman and its Use in the IKE > > Protocols", Advances in Cryptography - CRYPTO 2003 > > Proceedings LNCS 2729, 2003, > www.informatik.uni-trier.de/~ley/db/conf/crypto/ > > > crypto2003.html>._______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0056ED9888257877_= Content-Type: text/html; charset="US-ASCII"
> I contacted Hugo Krawczyk, the SIGMA author, and he agreed to
> evaluate the security considerations of the draft.  He's busy at the
> moment though so we won't be able to pick-up the thread for a couple weeks.

I reviewed the draft with Hugo and he explained that it is critical to sign something fresh (as opposed to something cached as proposed in the current version of the draft) and something that binds the data to the SA should be included (e.g. the SPIs).  The approach Hugo suggested was that the initiator should first send the responder the data to sign.  In practice this works out to four messages.  For example:
1) Host A generates some fresh data (i.e. a nonce) and sends it to host B ("here, sign my data")
2) Host B signs the fresh data from host A and sends it back ("ok, I signed your data, now you sign what I just sent")
3) Host A verifies the signature from host B, signs the data from host B and sends it back ("ok, I verified your data and signed it")
4) Host B verifies the signature from host A and responds with success or failure

The original version of the draft satisfied these requirements but the current version does not.  

The current version of the draft takes the approach of allowing a modified IKE_AUTH exchange on the original IKE SA, subsequent to the initial exchanges, for the express purpose of reauthentication.  It does not provide for signing fresh nonces.

The original version of the draft used the initial exchanges to reauthenticate the IKE SA (as is normally done in IKEv2) but added a notification mechanism indicating that the new IKE SA should inherit the old child SAs, thereby eliminating the round-trips that would have been required to re-establish equivalent child SAs under the new IKE SA.  

Therefore, I believe the approach taken in the original version of the draft is the best way forward for eliminating the unnecessary round-trips needed to re-establish child SAs during IKEv2 reauthentication (as well as solving the other problems identified by the draft).

>
> > > 2. There is one point I'd still like technical input on, namely the
> > > security considerations of signing the previous AUTH payload sent by the
> > > host in the modified IKE_AUTH exchange (section 5 of the draft).  Yoav
> > > suggested this approach, it sounded fine to me, I ran it by a
> couple of my
> > > colleagues (Scott Moonen and David Wierbowski) who thought it sound fine
> > > too so I used it in the new draft.  I'd feel better if another subject
> > > matter expert said, "yes, that is fine."  Bonus points if the SME can
> > > offer a sentence or two justifying why this mechanism is as secure as the
> > > authentication operation that takes place during the initial
> exchanges. It
> > > would be nice to include that information in the security considerations
> > > section of my draft.  More specifically, RFC 5996 section 2.15
> > > "Authentication of the IKE SA" says, "It is critical to the security of
> > > the exchange that each side sign the other side's nonce."  Is itnecessary
> > > to include nonces in the signed data in the proposed modified IKE_AUTH
> > > exchange?  I don't think so, but since I don't know why it was necessary
> > > as part of the signed data in the initial exchanges I don't feelqualified
> > > to assert that formally.
> >
> > In the initial authentication the signing of the IKE_SA message proofs
> > that nobody has modified those packets. Note, that it does not sign
> > the IKE_AUTH message, as it is protected by the Integrity Checksum
> > Data field. So the signing of the message data is there just to
> > provide MAC for the first packets which are not MACed normally.
> >
> > The real authentication happens when node signs the other ends nonce
> > and his own MACed ID.
> >
> > Read the SIGMA documentation for more details:
> >
> >    [SIGMA]    H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to
> >               Authenticated Diffie-Hellman and its Use in the IKE
> >               Protocols", Advances in Cryptography - CRYPTO 2003
> >               Proceedings LNCS 2729, 2003, <http://
> >               www.informatik.uni-trier.de/~ley/db/conf/crypto/
> >              
> crypto2003.html>._______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
 --=_alternative 0056ED9888257877_=-- From prbatra@cisco.com Wed Apr 27 05:04:48 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF98E06BF for ; Wed, 27 Apr 2011 05:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG6KMrhUBkSe for ; Wed, 27 Apr 2011 05:04:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6E024E069A for ; Wed, 27 Apr 2011 05:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=651; q=dns/txt; s=iport; t=1303905884; x=1305115484; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=y7ewgrRoNZr4HSCAkwLRN87J0FQpbCc6cqgEeJdTzWU=; b=N6YxFyZSEmXFyKA8L7QgEjqozN7S2d0bRQsMazayPK6vR0PN2nA/K7ha q5JEzFwEMN34cMI+A7m6uyWbXbvTKCMMUkKuMcaPLsA4PcfgzsbtDqeBs ZRXdYmvIwPvRmrQPwEDFswYk65U6nmSjzsHscIWxjw6hOdre6GVyDp3Sq 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQHAHYFuE2Q/khNgWdsb2JhbACYPY0uFAEBFiYlpU+ceoMAgnYEhgGMaoJSh0g X-IronPort-AV: E=Sophos;i="4.64,274,1301875200"; d="scan'208";a="85506239" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 27 Apr 2011 12:04:43 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3RC4gA3002944 for ; Wed, 27 Apr 2011 12:04:43 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 17:34:42 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Apr 2011 17:34:41 +0530 Message-ID: In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5EF280B@MX14A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Query regarding IKE_SA_AUTH response Thread-Index: Acv1IHxzokiKT8qKRcOB3RzT/jmIFAABlvfgA+pDY5A= References: <716209EC190CA740BA799AC4ACCBFB5D1851CEE70A@IXCAEXCH07.ixiacom.com><19868.21021.903247.236756@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E03E5EF280B@MX14A.corp.emc.com> From: "Prashant Batra (prbatra)" To: X-OriginalArrivalTime: 27 Apr 2011 12:04:42.0164 (UTC) FILETIME=[4A836F40:01CC04D3] Subject: [IPsec] Query regarding IKE_SA_AUTH response X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 12:04:48 -0000 Hi,=20 I have 2 doubts regarding IKEv2, 1) If in IKE_AUTH request message initiator sends a ID_R payload(optional) specifying a particular peer identity, and the responder sends some different identity in the ID_R payload, what should be the behavior? Should we send a AUTHENTICATION failure message,=20 or except this new identity of the peer and mark the SA established, if the other things are fine. 2) If we were to send a AUTHENTICATION failure, then this should be sent as a INFORMATIONAL exchange message (as the message received=20 is a response and not request). What should be the message Id used? Regards,=20 Prashant From smoonen@us.ibm.com Wed Apr 27 05:24:20 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAA9E069A; Wed, 27 Apr 2011 05:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QF2j81e+FJp5; Wed, 27 Apr 2011 05:24:16 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by ietfa.amsl.com (Postfix) with ESMTP id 5320BE0703; Wed, 27 Apr 2011 05:24:08 -0700 (PDT) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e31.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3RC81Ll002702; Wed, 27 Apr 2011 06:08:01 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3RCNvYD140144; Wed, 27 Apr 2011 06:23:57 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3RCSuNj004812; Wed, 27 Apr 2011 06:28:56 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3RCSuTc004805; Wed, 27 Apr 2011 06:28:56 -0600 In-Reply-To: References: <716209EC190CA740BA799AC4ACCBFB5D1851CEE70A@IXCAEXCH07.ixiacom.com><19868.21021.903247.236756@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E03E5EF280B@MX14A.corp.emc.com> X-KeepSent: 80916F96:9490F890-8525787F:00434D1C; type=4; name=$KeepSent To: "Prashant Batra (prbatra)" X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Scott C Moonen Date: Wed, 27 Apr 2011 08:23:51 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 04/27/2011 06:23:56 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBF2ECDFD0CB8C8f9e8a93df938690918c0ABBF2ECDFD0CB8C" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] Query regarding IKE_SA_AUTH response X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 12:24:20 -0000 --0__=0ABBF2ECDFD0CB8C8f9e8a93df938690918c0ABBF2ECDFD0CB8C Content-type: multipart/alternative; Boundary="1__=0ABBF2ECDFD0CB8C8f9e8a93df938690918c0ABBF2ECDFD0CB8C" --1__=0ABBF2ECDFD0CB8C8f9e8a93df938690918c0ABBF2ECDFD0CB8C Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Hi Prashant. > 1) If in IKE_AUTH request message initiator sends a ID_R > payload(optional) specifying a particular peer identity, and the > responder > sends some different identity in the ID_R payload, what should be the= > behavior? Should we send a AUTHENTICATION failure message, > or except this new identity of the peer and mark the SA established, = if > the other things are fine. This is an implementation decision. In general, you should not automatically reject the negotiation because the optional IDr is intend= ed only as a hint. Instead, you should (1) check whether your peer authorization database (PAD) allows you to converse with the new identi= ty at the given IP address and to protect the given traffic, and (2) be su= re to verify that any earlier decisions, such as the use of a particular pre-shared key or the choice of IKE SA cryptographic algorithms, are st= ill correct given that you are talking to a different identity than you fir= st suspected. > 2) If we were to send a AUTHENTICATION failure, then this should be s= ent > as a INFORMATIONAL exchange message (as the message received > is a response and not request). What should be the message Id used? Yes, if you were to determine that the peer identity is not permitted b= y your PAD, then you would initiate a new informational exchange on the I= KE SA. Since the IKE_AUTH exchange has a message id of 1, this exchange wo= uld have a message id of 2. My own preference would be to send both an AUTHENTICATION_FAILED payload and a delete payload for the IKE SA, for maximum clarity. But I think that sending only AUTHENTICATION_FAILED is= sufficient and would be the preference of others on this list. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: "Prashant Batra (prbatra)" To: Date: 04/27/2011 08:06 AM Subject: [IPsec] Query regarding IKE_SA_AUTH response Sent by: ipsec-bounces@ietf.org Hi, I have 2 doubts regarding IKEv2, 1) If in IKE_AUTH request message initiator sends a ID_R payload(optional) specifying a particular peer identity, and the responder sends some different identity in the ID_R payload, what should be the behavior? Should we send a AUTHENTICATION failure message, or except this new identity of the peer and mark the SA established, if= the other things are fine. 2) If we were to send a AUTHENTICATION failure, then this should be sen= t as a INFORMATIONAL exchange message (as the message received is a response and not request). What should be the message Id used? Regards, Prashant _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBF2ECDFD0CB8C8f9e8a93df938690918c0ABBF2ECDFD0CB8C Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hi Prashant.

> 1) If in IKE_AUTH request message initiator sends a ID_R
> payload(optional) specifying a particular peer identity, and the > responder
> sends some different identity in the ID_R payload, what should be = the
> behavior? Should we send a AUTHENTICATION failure message,
> or except this new identity of the peer and mark the SA establishe= d, if
> the other things are fine.

This is an implementation decision. In general, you should not automati= cally reject the negotiation because the optional IDr is intended only = as a hint. Instead, you should (1) check whether your peer authorizatio= n database (PAD) allows you to converse with the new identity at the gi= ven IP address and to protect the given traffic, and (2) be sure to ver= ify that any earlier decisions, such as the use of a particular pre-sha= red key or the choice of IKE SA cryptographic algorithms, are still cor= rect given that you are talking to a different identity than you first = suspected.

> 2) If we were to send a AUTHENTICATION failure, then this shou= ld be sent
> as a INFORMATIONAL exchange message (as the message received
> is a response and not request). What should be the message Id used= ?

Yes, if you were to determine that the peer identity is not permitted b= y your PAD, then you would initiate a new informational exchange on the= IKE SA. Since the IKE_AUTH exchange has a message id of 1, this exchan= ge would have a message id of 2. My own preference would be to send bot= h an AUTHENTICATION_FAILED payload and a delete payload for the IKE SA,= for maximum clarity. But I think that sending only AUTHENTICATION_FAIL= ED is sufficient and would be the preference of others on this list.

Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/= in/smoonen

3D"Inactive"Prashant Batr= a (prbatra)" ---04/27/2011 08:06:01 AM---Hi, I have 2 doubts rega= rding IKEv2,

From: "= Prashant Batra (prbatra)" <prbatra@cisco.com>
To: <ipse= c@ietf.org>
Date: 04/27/= 2011 08:06 AM
Subject: [IP= sec] Query regarding IKE_SA_AUTH response
Sent by: ips= ec-bounces@ietf.org




Hi,

I have 2 doubts regarding IKEv2,

1) If in IKE_AUTH request message initiator sends a ID_R
payload(optional) specifying a particular peer identity, and the
responder
sends some different identity in the ID_R payload, what should be the behavior? Should we send a AUTHENTICATION failure message,
or except this new identity of the peer and mark the SA established, if=
the other things are fine.

2) If we were to send a AUTHENTICATION failure, then this should be sen= t
as a INFORMATIONAL exchange message (as the message received
is a response and not request). What should be the message Id used?
=
Regards,
Prashant



_______________________________________________
IPsec mailing list
IPsec@ietf.org
https:= //www.ietf.org/mailman/listinfo/ipsec

= --1__=0ABBF2ECDFD0CB8C8f9e8a93df938690918c0ABBF2ECDFD0CB8C-- --0__=0ABBF2ECDFD0CB8C8f9e8a93df938690918c0ABBF2ECDFD0CB8C Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBF2ECDFD0CB8C8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF2ECDFD0CB8C8f9e8a93df938690918c0ABBF2ECDFD0CB8C-- From prbatra@cisco.com Wed Apr 27 06:39:49 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16DDE0708 for ; Wed, 27 Apr 2011 06:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.388 X-Spam-Level: X-Spam-Status: No, score=-9.388 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zN3DG15v1Vjt for ; Wed, 27 Apr 2011 06:39:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B4C51E06DD for ; Wed, 27 Apr 2011 06:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=13889; q=dns/txt; s=iport; t=1303911584; x=1305121184; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=NHqXXgQFRBXEEveB+/VjJzxpvWsWwE21XFl2IgApkQE=; b=aVcEJKFvWV+dSP2ypk2YW4Lm8ViZRN+9Vy0GKbmCk8bR5gCI2BH6vQ7d o9HtgU1ZwRcI965gYsD/Y3+NpaqxnFdIJyNEggeCFbi0Z6MI78b2fy2Bv P/gHxp4WJ6EwCD/1W/na7o5RcutsGE0muuXZZ4PA7JOkf0Y2AduM8feWR g=; X-Files: image001.gif : 105 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgCABMcuE2Q/khRgWdsb2JhbACCEFKVHI1tFAEBFiYliHCdZJxygwCCdgSGAYJkigaCUodI X-IronPort-AV: E=Sophos;i="4.64,274,1301875200"; d="gif'147?scan'147,208,217,147";a="85524855" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 27 Apr 2011 13:39:43 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3RDdgWd025151; Wed, 27 Apr 2011 13:39:42 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 19:09:41 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CC04E0.8F49F792"; type="multipart/alternative" Date: Wed, 27 Apr 2011 19:09:40 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Query regarding IKE_SA_AUTH response Thread-Index: AcwE1g2U7ParDlysTtudciZWx8xJ9gACacCQ References: <716209EC190CA740BA799AC4ACCBFB5D1851CEE70A@IXCAEXCH07.ixiacom.com><19868.21021.903247.236756@fireball.kivinen.iki.fi><7C4DFCE962635144B8FAE8CA11D0BF1E03E5EF280B@MX14A.corp.emc.com> From: "Prashant Batra (prbatra)" To: "Scott C Moonen" , X-OriginalArrivalTime: 27 Apr 2011 13:39:41.0060 (UTC) FILETIME=[8F51F440:01CC04E0] Subject: Re: [IPsec] Query regarding IKE_SA_AUTH response X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 13:39:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC04E0.8F49F792 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC04E0.8F49F792" ------_=_NextPart_002_01CC04E0.8F49F792 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Scott, =20 I also prefer sending the AUTHENTICATION FAILED and a DELETE PAYLOAD, so as to ensure that the peer deletes the ipsec tunnel from the SADB (as it would have already added the tunnel in SADB, after sending the AUTH_RESPONSE). But, to second you, most implementations would delete the same on receiving AUTHENTICATION FAILED alone. =20 Regards,=20 Prashant =20 =20 From: Scott C Moonen [mailto:smoonen@us.ibm.com]=20 Sent: Wednesday, April 27, 2011 5:54 PM To: Prashant Batra (prbatra) Cc: ipsec@ietf.org; ipsec-bounces@ietf.org Subject: Re: [IPsec] Query regarding IKE_SA_AUTH response =20 Hi Prashant. > 1) If in IKE_AUTH request message initiator sends a ID_R > payload(optional) specifying a particular peer identity, and the > responder > sends some different identity in the ID_R payload, what should be the > behavior? Should we send a AUTHENTICATION failure message,=20 > or except this new identity of the peer and mark the SA established, if > the other things are fine. This is an implementation decision. In general, you should not automatically reject the negotiation because the optional IDr is intended only as a hint. Instead, you should (1) check whether your peer authorization database (PAD) allows you to converse with the new identity at the given IP address and to protect the given traffic, and (2) be sure to verify that any earlier decisions, such as the use of a particular pre-shared key or the choice of IKE SA cryptographic algorithms, are still correct given that you are talking to a different identity than you first suspected. > 2) If we were to send a AUTHENTICATION failure, then this should be sent > as a INFORMATIONAL exchange message (as the message received=20 > is a response and not request). What should be the message Id used? Yes, if you were to determine that the peer identity is not permitted by your PAD, then you would initiate a new informational exchange on the IKE SA. Since the IKE_AUTH exchange has a message id of 1, this exchange would have a message id of 2. My own preference would be to send both an AUTHENTICATION_FAILED payload and a delete payload for the IKE SA, for maximum clarity. But I think that sending only AUTHENTICATION_FAILED is sufficient and would be the preference of others on this list. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen "Prashant Batra (prbatra)" ---04/27/2011 08:06:01 AM---Hi, I have 2 doubts regarding IKEv2, From: "Prashant Batra (prbatra)" To: Date: 04/27/2011 08:06 AM Subject: [IPsec] Query regarding IKE_SA_AUTH response Sent by: ipsec-bounces@ietf.org ________________________________ Hi,=20 I have 2 doubts regarding IKEv2, 1) If in IKE_AUTH request message initiator sends a ID_R payload(optional) specifying a particular peer identity, and the responder sends some different identity in the ID_R payload, what should be the behavior? Should we send a AUTHENTICATION failure message,=20 or except this new identity of the peer and mark the SA established, if the other things are fine. 2) If we were to send a AUTHENTICATION failure, then this should be sent as a INFORMATIONAL exchange message (as the message received=20 is a response and not request). What should be the message Id used? Regards,=20 Prashant _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_002_01CC04E0.8F49F792 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Scott,

 

 I also prefer sending the AUTHENTICATION FAILED and = a DELETE PAYLOAD, so as to ensure that the peer deletes the ipsec tunnel from the = SADB (as it would have already added the tunnel in SADB, after sending the = AUTH_RESPONSE).

But, to second you, most implementations would delete the = same on receiving AUTHENTICATION FAILED alone.

 

Regards,

Prashant

 

 

From:= Scott C = Moonen [mailto:smoonen@us.ibm.com]
Sent: Wednesday, April 27, 2011 5:54 PM
To: Prashant Batra (prbatra)
Cc: ipsec@ietf.org; ipsec-bounces@ietf.org
Subject: Re: [IPsec] Query regarding IKE_SA_AUTH = response

 

Hi Prashant.

> 1) If in IKE_AUTH request = message initiator sends a ID_R
> payload(optional) specifying a particular peer identity, and = the
> responder
> sends some different identity in the ID_R payload, what should = be the
> behavior? Should we send a AUTHENTICATION failure message, =
> or except this new identity of the peer and mark the SA = established, if
> the other things are fine.

This is an implementation decision. In general, you should not = automatically reject the negotiation because the optional IDr is intended only as a = hint. Instead, you should (1) check whether your peer authorization database = (PAD) allows you to converse with the new identity at the given IP address and = to protect the given traffic, and (2) be sure to verify that any earlier decisions, such as the use of a particular pre-shared key or the choice = of IKE SA cryptographic algorithms, are still correct given that you are = talking to a different identity than you first suspected.

> 2) If we were to send a = AUTHENTICATION failure, then this should be sent
> as a INFORMATIONAL exchange message (as the message received =
> is a response and not request). What should be the message Id = used?

Yes, if you were to determine that the peer identity is not permitted by = your PAD, then you would initiate a new informational exchange on the IKE SA. = Since the IKE_AUTH exchange has a message id of 1, this exchange would have a = message id of 2. My own preference would be to send both an = AUTHENTICATION_FAILED payload and a delete payload for the IKE SA, for maximum clarity. But I = think that sending only AUTHENTICATION_FAILED is sufficient and would be the preference of others on this list.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/sm= oonen

3D"Inactive"Prashant Batra (prbatra)" = ---04/27/2011 08:06:01 AM---Hi, I have 2 doubts regarding IKEv2,

From: "Prashant Batra (prbatra)" <prbatra@cisco.com>
To: <ipsec@ietf.org>
Date: 04/27/2011 08:06 AM
Subject: [IPsec] Query regarding IKE_SA_AUTH = response
Sent by: ipsec-bounces@ietf.org




Hi,

I have 2 doubts regarding IKEv2,

1) If in IKE_AUTH request message initiator sends a ID_R
payload(optional) specifying a particular peer identity, and = the
responder
sends some different identity in the ID_R payload, what should be = the
behavior? Should we send a AUTHENTICATION failure message,
or except this new identity of the peer and mark the SA established, = if
the other things are fine.

2) If we were to send a AUTHENTICATION failure, then this should be = sent
as a INFORMATIONAL exchange message (as the message received =
is a response and not request). What should be the message Id = used?

Regards,
Prashant



_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org= /mailman/listinfo/ipsec

------_=_NextPart_002_01CC04E0.8F49F792-- ------_=_NextPart_001_01CC04E0.8F49F792 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------_=_NextPart_001_01CC04E0.8F49F792-- From rsjenwar@gmail.com Wed Apr 27 21:22:27 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69010E07CE for ; Wed, 27 Apr 2011 21:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMVHNIIMpgGG for ; Wed, 27 Apr 2011 21:22:26 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E566E0680 for ; Wed, 27 Apr 2011 21:22:26 -0700 (PDT) Received: by yic13 with SMTP id 13so1032940yic.31 for ; Wed, 27 Apr 2011 21:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dPUodWYV4vLDDbqYqYt8dSOZdmDool68Lrg32LhBuJw=; b=SuFJ62PeiPLMjW9z24dpnR+a+PvlmpHwu+ji5xr85OL5BsJBYVfUsvKpRimBiAymEr aDPccjm7FBefdRMmiEQ1vzoGHnnd3+HKCyNYMfn2Juks5hkdmRt5yyC1+s3AwAYFLLnq T4je4g/Grky7Pn3iR2oPpJvb0Kmy+YcBIXf8Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=QvCbU1w/lQqXdKwd2ApgDFp1/IS1gYoFMT9ktfYzC/c9OMW618DgsKilsheKNtGpuz e40p646aIzkbtJ5je2zPeVUI7KK4XeBd+Txu+QPd6GiXoyFRDsD9HbWMNnvmeUle8M3u uwE75REzAmup8nUk8VkexA6rDsyS1dkXbqbrQ= MIME-Version: 1.0 Received: by 10.147.165.11 with SMTP id s11mr2610961yao.3.1303964545475; Wed, 27 Apr 2011 21:22:25 -0700 (PDT) Received: by 10.147.99.17 with HTTP; Wed, 27 Apr 2011 21:22:25 -0700 (PDT) In-Reply-To: References: <716209EC190CA740BA799AC4ACCBFB5D1851CEE70A@IXCAEXCH07.ixiacom.com> <19868.21021.903247.236756@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E03E5EF280B@MX14A.corp.emc.com> Date: Thu, 28 Apr 2011 09:52:25 +0530 Message-ID: From: Raj Singh To: "Prashant Batra (prbatra)" Content-Type: multipart/alternative; boundary=00151758b5c08866e204a1f2e7b2 Cc: ipsec@ietf.org Subject: Re: [IPsec] Query regarding IKE_SA_AUTH response X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: RSJenwar@gmail.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 04:22:27 -0000 --00151758b5c08866e204a1f2e7b2 Content-Type: text/plain; charset=UTF-8 Hi Prashant, As per RFC 5996, Initiator sending AUTHENTICATION_FAILED would be sufficient in case of peer's authentication failure: Sec. 2.21.2 Error Handling in IKE_AUTH ... If the error occurs on the initiator, the notification MAY be returned in a separate INFORMATIONAL exchange, usually with no other payloads. This is an exception for the general rule of not starting new exchanges based on errors in responses. ... In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately following it (in case an error happened when processing a response to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and AUTHENTICATION_FAILED notifications are the only ones to cause the IKE SA to be deleted or not created, without a Delete payload. ... Regards, Raj On Wed, Apr 27, 2011 at 7:09 PM, Prashant Batra (prbatra) wrote: > Thanks Scott, > > > > I also prefer sending the AUTHENTICATION FAILED and a DELETE PAYLOAD, so > as to ensure that the peer deletes the ipsec tunnel from the SADB (as it > would have already added the tunnel in SADB, after sending the > AUTH_RESPONSE). > > But, to second you, most implementations would delete the same on receiving > AUTHENTICATION FAILED alone. > > > > Regards, > > Prashant > > > > > > *From:* Scott C Moonen [mailto:smoonen@us.ibm.com] > *Sent:* Wednesday, April 27, 2011 5:54 PM > *To:* Prashant Batra (prbatra) > *Cc:* ipsec@ietf.org; ipsec-bounces@ietf.org > *Subject:* Re: [IPsec] Query regarding IKE_SA_AUTH response > > > > Hi Prashant. > > > 1) If in IKE_AUTH request message initiator sends a ID_R > > payload(optional) specifying a particular peer identity, and the > > responder > > sends some different identity in the ID_R payload, what should be the > > behavior? Should we send a AUTHENTICATION failure message, > > or except this new identity of the peer and mark the SA established, if > > the other things are fine. > > This is an implementation decision. In general, you should not > automatically reject the negotiation because the optional IDr is intended > only as a hint. Instead, you should (1) check whether your peer > authorization database (PAD) allows you to converse with the new identity at > the given IP address and to protect the given traffic, and (2) be sure to > verify that any earlier decisions, such as the use of a particular > pre-shared key or the choice of IKE SA cryptographic algorithms, are still > correct given that you are talking to a different identity than you first > suspected. > > > 2) If we were to send a AUTHENTICATION failure, then this should be sent > > as a INFORMATIONAL exchange message (as the message received > > is a response and not request). What should be the message Id used? > > Yes, if you were to determine that the peer identity is not permitted by > your PAD, then you would initiate a new informational exchange on the IKE > SA. Since the IKE_AUTH exchange has a message id of 1, this exchange would > have a message id of 2. My own preference would be to send both an > AUTHENTICATION_FAILED payload and a delete payload for the IKE SA, for > maximum clarity. But I think that sending only AUTHENTICATION_FAILED is > sufficient and would be the preference of others on this list. > > > Scott Moonen (smoonen@us.ibm.com) > z/OS Communications Server TCP/IP Development > http://www.linkedin.com/in/smoonen > > [image: Inactive hide details for "Prashant Batra (prbatra)" ---04/27/2011 > 08:06:01 AM---Hi, I have 2 doubts regarding IKEv2,]"Prashant Batra > (prbatra)" ---04/27/2011 08:06:01 AM---Hi, I have 2 doubts regarding IKEv2, > > From: "Prashant Batra (prbatra)" > To: > Date: 04/27/2011 08:06 AM > Subject: [IPsec] Query regarding IKE_SA_AUTH response > Sent by: ipsec-bounces@ietf.org > ------------------------------ > > > > > Hi, > > I have 2 doubts regarding IKEv2, > > 1) If in IKE_AUTH request message initiator sends a ID_R > payload(optional) specifying a particular peer identity, and the > responder > sends some different identity in the ID_R payload, what should be the > behavior? Should we send a AUTHENTICATION failure message, > or except this new identity of the peer and mark the SA established, if > the other things are fine. > > 2) If we were to send a AUTHENTICATION failure, then this should be sent > as a INFORMATIONAL exchange message (as the message received > is a response and not request). What should be the message Id used? > > Regards, > Prashant > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --00151758b5c08866e204a1f2e7b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Prashant,

As per RFC 5996, Initiator sending AUTHENTICATION_FAILE= D would be sufficient in case of peer's authentication failure:

= Sec. 2.21.2 Error Handling in IKE_AUTH

...

If the error occurs on the initiator, the notification MAY=
 be
returned in a separate INFORMATIONAL exchange, usually with no other
payloads.  This is an exception for the general rule of not starting
new exchanges based on errors in responses.

...
In an IKE_AUTH exchange, or in the INFO= RMATIONAL exchange immediately following it (in case an error happened when processing a response to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and AUTHENTICATION_FAILED notifications are the only ones to cause the IKE SA to be deleted or not created, without a Delete payload.
...

Regards,
Raj



On Wed, Apr 27, 2011 at 7:09 PM, Prashan= t Batra (prbatra) <prbatra@cisco.com> wrote:

Thank= s Scott,

=C2= =A0

=C2= =A0I also prefer sending the AUTHENTICATION FAILED and a DELETE PAYLOAD, so as to ensure that the peer deletes the ipsec tunnel from the SA= DB (as it would have already added the tunnel in SADB, after sending the AUTH_= RESPONSE).

But, = to second you, most implementations would delete the same on receiving AUTHENTICATION FAILED alone.

=C2= =A0

Regar= ds,

Prash= ant

=C2= =A0

=C2= =A0

From:= Scott C Moonen [mailto:smoonen@us.= ibm.com]
Sent: Wednesday, April 27, 2011 5:54 PM
To: Prashant Batra (prbatra)
Cc: ipsec@ietf.o= rg; ipsec-b= ounces@ietf.org
Subject: Re: [IPsec] Query regarding IKE_SA_AUTH response

=C2=A0

Hi Prashant.

> 1) If in IKE_AUTH request message initiator sends a ID_R
> payload(optional) specifying a particular peer identity, and the
> responder
> sends some different identity in the ID_R payload, what should be = the
> behavior? Should we send a AUTHENTICATION failure message, > or except this new identity of the peer and mark the SA establishe= d, if
> the other things are fine.

This is an implementation decision. In general, you should not automaticall= y reject the negotiation because the optional IDr is intended only as a hint. Instead, you should (1) check whether your peer authorization database (PAD= ) allows you to converse with the new identity at the given IP address and to protect the given traffic, and (2) be sure to verify that any earlier decisions, such as the use of a particular pre-shared key or the choice of = IKE SA cryptographic algorithms, are still correct given that you are talking t= o a different identity than you first suspected.

> 2) If we were to send a AUTHENTIC= ATION failure, then this should be sent
> as a INFORMATIONAL exchange message (as the message received =
> is a response and not request). What should be the message Id used= ?

Yes, if you were to determine that the peer identity is not permitted by yo= ur PAD, then you would initiate a new informational exchange on the IKE SA. Si= nce the IKE_AUTH exchange has a message id of 1, this exchange would have a mes= sage id of 2. My own preference would be to send both an AUTHENTICATION_FAILED payload and a delete payload for the IKE SA, for maximum clarity. But I thi= nk that sending only AUTHENTICATION_FAILED is sufficient and would be the preference of others on this list.


Scott Moonen (smoon= en@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www= .linkedin.com/in/smoonen

3D"Inactive"Prashant Ba= tra (prbatra)" ---04/27/2011 08:06:01 AM---Hi, I have 2 doubts regarding IKEv2,

From: "Prashant Batra (prbatra)" <prbatra@cisco.co= m>
To: <ips= ec@ietf.org>
Date: 04/27/2011 08:06 AM
Subject: [IPsec] Query regarding IKE_SA_AUTH response Sent by: ipsec-bounces@ietf.org




Hi,

I have 2 doubts regarding IKEv2,

1) If in IKE_AUTH request message initiator sends a ID_R
payload(optional) specifying a particular peer identity, and the responder
sends some different identity in the ID_R payload, what should be the
behavior? Should we send a AUTHENTICATION failure message,
or except this new identity of the peer and mark the SA established, if=
the other things are fine.

2) If we were to send a AUTHENTICATION failure, then this should be sen= t
as a INFORMATIONAL exchange message (as the message received
is a response and not request). What should be the message Id used?

Regards,
Prashant



_______________________________________________
IPsec mailing list
IPsec@ietf.org<= /tt>
https://www.ietf.org/mailman/listinfo/ipsec


_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec


--00151758b5c08866e204a1f2e7b2--