[IPsec] Fw: Preshared key authentication in IKEv2

"Valery Smyslov" <svanru@gmail.com> Fri, 30 October 2009 06:58 UTC

Return-Path: <svanru@gmail.com>
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 B22D43A63D3 for <ipsec@core3.amsl.com>; Thu, 29 Oct 2009 23:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.627
X-Spam-Level:
X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, GB_I_LETTER=-2, J_CHICKENPOX_36=0.6, XMAILER_MIMEOLE_OL_7533E=0.513]
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 GMwkncGk72gP for <ipsec@core3.amsl.com>; Thu, 29 Oct 2009 23:58:30 -0700 (PDT)
Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by core3.amsl.com (Postfix) with ESMTP id 5CA573A6821 for <ipsec@ietf.org>; Thu, 29 Oct 2009 23:58:30 -0700 (PDT)
Received: by ewy5 with SMTP id 5so742789ewy.37 for <ipsec@ietf.org>; Thu, 29 Oct 2009 23:58:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:subject :date:mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=RP9TOIOZaEdGiwwqR6A6jNnR/WNFaMWnS4HP0Jiwx/c=; b=eUqwxchpC223+0jsbAC2D8S6Xhj7mt7uoRgbmTpVruDd8XjdgKT+ntx8dh5OCFBU2v NN+x0YUxcQw0Zb48VWDiQ0YZ3y3b22/tLWwhWMTc7OQlBuyMKaBeRPeT94ksyrL8iSaR +lHS8xcAWqra+oi157hRWue2mhBAWgxcdNvW8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; b=x1+k2IStVgb9mv5ocHoTtYKOs5X4HwrVR7kOgkN71jgTYZ+0+p3vPFRyX1JqIbeqi1 UpwYvVTavtaxMV+0sbCGiDRPwxMAAZQWFUZg1l0UjklBL26nWMf1N16u5uCRS+0lWHsv dCh0d+P7cfMVFBVEzvaMGZJ45DW6pq8pQ3N1k=
Received: by 10.210.7.23 with SMTP id 23mr3789934ebg.38.1256885922951; Thu, 29 Oct 2009 23:58:42 -0700 (PDT)
Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 28sm7941027eyg.22.2009.10.29.23.58.40 (version=SSLv3 cipher=RC4-MD5); Thu, 29 Oct 2009 23:58:41 -0700 (PDT)
Message-ID: <82DFB96E88E54DE98E9B6B5F766C3EB8@trustworks.com>
From: "Valery Smyslov" <svanru@gmail.com>
To: <ipsec@ietf.org>
Date: Fri, 30 Oct 2009 09:58:44 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4963.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700
Subject: [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: Fri, 30 Oct 2009 06:58:31 -0000

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?
2. It is a bit unclear whether EAP generated key should also
    be padded before use in IKE, or used directly.

Thanks,
Valery Smyslov.


----- Original Message -----
From: "Valery Smyslov" <svanru@gmail.com>;
To: <ipsec@ietf.org>;
Subject: [IPsec] Preshared key authentication in IKEv2


> Hi all,
>
> I found text describing preshared key authentication in IKEv2 a bit
confusing.
>
> First, in section 2.15 four different terms are used: "shared secret",
> "Shared Secret" (with capital letters), "shared key" and "pre-shared key".
> This is a bit confusing, especially taking into consideration that terms
> "shared keys" and "shared secret" are also used in the draft for SK_* and
> result of ephemeral Diffie-Hellman exchange. I'd propose to use
> only one term, "pre-shared key".
>
> Then, in section 2.15 the very first sentence states:
>
>      When not using extensible authentication (see Section 2.16), the
>      peers are authenticated by having each sign (or MAC using a shared
>      secret as the key) a block of data.
>
> But in the last paragraph of this section it is shown, that not sole
"shared
> secret"
> is used as the key, but the following construction:
>
>     prf( Shared Secret,"Key Pad for IKEv2")
>
> So, the first sentence of 2.15 is misleading.
>
> Then, the following rationale for padding shared key is given:
>
>      The pad string is added so that if the shared secret is derived from
a
>      password, the IKE implementation need not store the password in
>      cleartext, but rather can store the value prf(Shared Secret,"Key Pad
>      for IKEv2"), which could not be used as a password equivalent for
>      protocols other than IKEv2.
>
> I found this rationale a bit strange, because which prf should be used
cannot
> be known at the time of providing pre-shared key by user - it becomes
known
> only after IKE_SA_INIT exchange is finished. It is possible to compute
values
> for all possible prfs, but this doesn't work in all cases - for example
> in case of pluggable crypto. So, I think, in general, storing of "Shared
> Secret"/password in unavoidable.
>
> And last, but not least. The following section 2.16, describing
> authentication with EAP, states:
>
>      For EAP methods that create a shared key as a side effect of
>      authentication, that shared key MUST be used by both the initiator
>      and responder to generate AUTH payloads in messages 7 and 8 using the
>      syntax for shared secrets specified in Section 2.15.
>
> and later:
>
>      If EAP methods that do not generate a
>      shared key are used, the AUTH payloads in messages 7 and 8 MUST be
>      generated using SK_pi and SK_pr, respectively.
>
> It is a bit unclear, whether these shared secrets (EAP generated or SK_p*)
> must be used as key "as is", or as  prf( SK_p*, "Key Pad for
> IKEv2").
> I suspect that the latter is right answer, but this probably must be
written
> excplicitly.
>
> Regards,
> Valery Smyslov.
>
>