Re: [IPsec] Fw: Preshared key authentication in IKEv2

Tero Kivinen <kivinen@iki.fi> Mon, 02 November 2009 14:13 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B37E3A6806 for <ipsec@core3.amsl.com>; Mon, 2 Nov 2009 06:13:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.217
X-Spam-Level:
X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_36=0.6]
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 zZ538YQddo8S for <ipsec@core3.amsl.com>; Mon, 2 Nov 2009 06:13:24 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 11F2C3A659B for <ipsec@ietf.org>; Mon, 2 Nov 2009 06:13:23 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id nA2EDbbh005849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 16:13:37 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nA2EDakG003003; Mon, 2 Nov 2009 16:13:36 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19182.59664.628328.76563@fireball.kivinen.iki.fi>
Date: Mon, 2 Nov 2009 16:13:36 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <p06240896c710cc6eae34@[10.20.30.158]>
References: <82DFB96E88E54DE98E9B6B5F766C3EB8@trustworks.com> <p06240896c710cc6eae34@[10.20.30.158]>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 9 min
X-Total-Time: 10 min
Cc: ipsec@ietf.org, Valery Smyslov <svanru@gmail.com>
Subject: Re: [IPsec] Fw: Preshared key authentication in IKEv2
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2009 14:13:25 -0000

Paul Hoffman writes:
> At 9:58 AM +0300 10/30/09, Valery Smyslov wrote:
> >Hi all,
> >
> >I'd like to reiterate my early message, which I haven't got answer to.
> >My concerns are:
> >
> >1. How padding pre-sahred key with string "Key Pad for IKEv2"
> >    could help to avoid storing pre-shared key in IKE implementation
> >    if prf is not known untill IKE_SA_INIT exchange is finished?
> 
> The PRF (or set of PRFs) is known by the receiving party. If the two
> parties always only use one PRF, it is known. The padding is not a
> universal solution for the reasons you give, but it works in the
> common case of peers who know each other's crypto choices.

As Paul said recipient knows which algorithms it support, and it can
store the pre-shared key using all of those algoritms to its database.
I.e. if it supports PRF_HMAC_SHA1, and PRF_AES128_XCBC then it needs
to calculate the PRF(Shared Secret, "Key Pad for IKEv2") using those
two PRFs and store both of the results to its authentication database.

This way if someone manages to get the authentication database it
cannot directly know the Shared Secret, it just knows the hash, and
cannot use the Shared Secret in any other protocols.

> >2. It is a bit unclear whether EAP generated key should also
> >    be padded before use in IKE, or used directly.
> 
> I'm pretty sure the key is used in its PRF form, not in its "as is"
> form, but I would want to hear from one or two implementers on that. 

As section 2.16 refers to the 2.15 and says the AUTH payloads in
messages 7 and 8 using the syntax for shared secrets specified in
section 2.15, and section 2.15 tells that this padding is used, so I
think it should be used always (and by quick look in our code seemed
to use the same format for both cases). 
-- 
kivinen@iki.fi