From Hannes.Tschofenig@gmx.net Sun Mar 1 11:45:30 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACADA3A6BC5 for ; Sun, 1 Mar 2009 11:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599] 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 ZxUakfXItHpH for ; Sun, 1 Mar 2009 11:45:30 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8BBD13A69F5 for ; Sun, 1 Mar 2009 11:45:29 -0800 (PST) Received: (qmail invoked by alias); 01 Mar 2009 19:39:08 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp054) with SMTP; 01 Mar 2009 20:39:08 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX193Lfon6yx3vRRZxAIoStRLKjUXsxwqagQvfoMho1 GX/SxWvgFufJxR From: "Hannes Tschofenig" To: "'ECRIT'" , "'KEYPROV'" , Date: Sun, 1 Mar 2009 21:40:04 +0200 Message-ID: <00ab01c99aa5$88024020$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcmYSIQ2rlgWDFaARwS44XtqzrJYLwCXO13g X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: [KEYPROV] FW: Initial Version I-D Submission Deadline Extended to March 4, 2009 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 19:45:30 -0000 FYI; more time in case you work on new documents. Ciao Hannes >-----Original Message----- >From: wgchairs-bounces@ietf.org >[mailto:wgchairs-bounces@ietf.org] On Behalf Of Alexa Morris >Sent: 26 February, 2009 21:28 >To: ietf-announce@ietf.org; ietf@ietf.org; wgchairs@ietf.org >Subject: Initial Version I-D Submission Deadline Extended to >March 4, 2009 > >The IESG has extended the deadline for initial version (00) >submissions of Internet Drafts by 2 days (48 hours). The new >deadline is March 4, 2009 at 1700 Pacific (March 5, 2009 at >0100 UTC / GMT) and the extension is for IETF 74 only. The >deadline has been extended due to the copyright legend text >alternative being recently finalized, approved and implemented. > >Please note that the date for updated I-D versions has NOT >been extended, and is still March 9, 2009. > >Regards, >Alexa > >----------- >Alexa Morris / Executive Director / IETF >48377 Fremont Blvd., Suite 117, Fremont, CA 94538 >Phone: +1.510.492.4089 / Fax: +1.510.492.4001 >Email: amorris@amsl.com > >Managed by Association Management Solutions (AMS) Forum >Management, Meeting and Event Planning www.amsl.com > > From anders.rundgren@telia.com Mon Mar 2 12:12:23 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143DF3A694D for ; Mon, 2 Mar 2009 12:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 6uWNhybobp0e for ; Mon, 2 Mar 2009 12:12:22 -0800 (PST) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by core3.amsl.com (Postfix) with ESMTP id 03D6F3A6966 for ; Mon, 2 Mar 2009 12:12:21 -0800 (PST) Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C503162222 for keyprov@ietf.org; Mon, 2 Mar 2009 21:12:47 +0100 Message-ID: <1E43DD6C9755498DBEABCE6A84442D1D@AndersPC> From: "Anders Rundgren" To: "KEYPROV" Date: Mon, 2 Mar 2009 21:12:50 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DF_01C99B7B.A4F6CC10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.20661 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Subject: [KEYPROV] Algorithm choices - Take II X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 20:12:23 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00DF_01C99B7B.A4F6CC10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Interesting, alarming or just plain stupid, I have anyway come to the = conclusion that I on my part [*] will switch to AES256_CBC, SHA256 and = HMAC_SHA256 as default to hopefully be able to concentrate on = implementations and deployments, rather than getting stuck in "cryptic" = discussions that probably have pretty limited relevance for = key-provisioning schemes that only carries random, high-entropy data. I will not consider the AES KW variants because with a separate MAC you = can create more powerful schemes where you bind attributes to keys using = trusted hardware. Although server-to-client-HW-enforced = algorithm/key-usage may be a "luxury", I still think it looks a bit cool = in the "pamphlet" :-) Anders Rundgren *] http://android-keystore-v2.webpki.org ------=_NextPart_000_00DF_01C99B7B.A4F6CC10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Interesting, alarming or just plain = stupid, I have=20 anyway come to the conclusion that I on my part [*] will switch to = AES256_CBC,=20 SHA256 and HMAC_SHA256 as default to hopefully be able to concentrate on = implementations and deployments, rather than getting stuck in = "cryptic"=20 discussions that probably have pretty limited relevance for=20 key-provisioning schemes that only carries random, high-entropy=20 data.
 
I will not consider the AES KW = variants=20 because with a separate MAC you can create more powerful schemes where = you bind=20 attributes to keys using trusted hardware.  Although=20 server-to-client-HW-enforced algorithm/key-usage may be a "luxury", I = still=20 think it looks a bit cool in the "pamphlet" :-)
 
Anders Rundgren
*] http://android-keystore-v2= .webpki.org
 
------=_NextPart_000_00DF_01C99B7B.A4F6CC10-- From Hannes.Tschofenig@gmx.net Mon Mar 9 11:02:09 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41FA83A6CB0 for ; Mon, 9 Mar 2009 11:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.138 X-Spam-Level: X-Spam-Status: No, score=-1.138 tagged_above=-999 required=5 tests=[AWL=-0.954, BAYES_40=-0.185, HTML_MESSAGE=0.001] 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 MxotQxqjpjiU for ; Mon, 9 Mar 2009 11:02:08 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B96673A6358 for ; Mon, 9 Mar 2009 11:02:04 -0700 (PDT) Received: (qmail invoked by alias); 09 Mar 2009 18:02:36 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp005) with SMTP; 09 Mar 2009 19:02:36 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/uwmBvy6nuwtg0qUBrHvE/DWjg1y9Z6OQIbD+iu6 R0sihsxC30xWOm From: "Hannes Tschofenig" To: "'KEYPROV'" Date: Mon, 9 Mar 2009 20:03:41 +0200 Message-ID: <004101c9a0e1$62185f60$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01C9A0F2.25A12F60" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acmg4WDRpTATAno1Tg2zfDRnHeHYzA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.84,0.85 Subject: [KEYPROV] AGENDA X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 18:02:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0042_01C9A0F2.25A12F60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Here is the first version of the meeting agenda: http://www.ietf.org/proceedings/09mar/agenda/keyprov.txt ------=_NextPart_000_0042_01C9A0F2.25A12F60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable AGENDA

Here is the first version of the = meeting agenda:
http://www.ietf.org/proceedings/09mar/agenda/keyprov.txt<= /A>

------=_NextPart_000_0042_01C9A0F2.25A12F60-- From anders.rundgren@telia.com Mon Mar 9 12:52:01 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263F53A684B for ; Mon, 9 Mar 2009 12:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_50=0.001] 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 6P0rKhMoCCqM for ; Mon, 9 Mar 2009 12:52:00 -0700 (PDT) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by core3.amsl.com (Postfix) with ESMTP id 3B1FB3A685A for ; Mon, 9 Mar 2009 12:52:00 -0700 (PDT) Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn1.fre.skanova.net (7.3.129) id 4843FAEB041A71E4; Mon, 9 Mar 2009 20:52:33 +0100 Message-ID: <61572DE9F3FF44DF9DEA5A251F9EE94C@AndersPC> From: "Anders Rundgren" To: "Hannes Tschofenig" , "'KEYPROV'" References: <004101c9a0e1$62185f60$0201a8c0@nsnintra.net> In-Reply-To: <004101c9a0e1$62185f60$0201a8c0@nsnintra.net> Date: Mon, 9 Mar 2009 20:52:37 +0100 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 Windows Mail 6.0.6000.20661 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Subject: Re: [KEYPROV] AGENDA X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 19:52:01 -0000 Although I won't be at the IETF meeting, I think it could be worthwhile checking if there is any interest in creating a browser-interface for protocols like DSKPP and KeyGen2. My suggestion is that such parties do a joint Open Source effort on WebKIT which is powering Mac, iPhone, S60, and Android. The other "camps" will most likely follow when this has been launched! Anders ----- Original Message ----- From: Hannes Tschofenig To: 'KEYPROV' Sent: Monday, March 09, 2009 19:03 Subject: [KEYPROV] AGENDA Here is the first version of the meeting agenda: http://www.ietf.org/proceedings/09mar/agenda/keyprov.txt _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov From philip.hoyer@actividentity.com Tue Mar 10 04:05:05 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DB7128C147 for ; Tue, 10 Mar 2009 04:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] 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 cMIV40SvRDRp for ; Tue, 10 Mar 2009 04:05:04 -0700 (PDT) Received: from frhub1.activcard.fr (frhub1.activcard.fr [91.151.120.133]) by core3.amsl.com (Postfix) with ESMTP id C5EF728C143 for ; Tue, 10 Mar 2009 04:05:03 -0700 (PDT) Received: from sur-corp-ex-02.corp.ad.activcard.com (sur-corp-ex-02.corp.ad.activcard.com [192.168.33.40]) by frhub1.activcard.fr (Postfix) with ESMTP id 458C71838F1; Tue, 10 Mar 2009 12:05:37 +0100 (CET) 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_01C9A170.96C9D5B4" Date: Tue, 10 Mar 2009 12:08:49 +0100 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB72C6@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt Thread-Index: AcmgzfVynxWuss1kSxyAQXXJ7CNInQAoLTCA References: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB723A@sur-corp-ex-02.corp.ad.activcard.com> From: "Philip Hoyer" To: "David Dix" Cc: keyprov@ietf.org Subject: Re: [KEYPROV] [OATH Technical] FW: WGLC: draft-ietf-keyprov-pskc-02.txt X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 11:05:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A170.96C9D5B4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David, Thanks for reviewing the spec. =20 You are right the example is incorrect. =20 The padding needs to be explicitly specified. In previous drafts and comments we agreed on PKCS#5 padding. =20 The MAC is on the unencrypted value since it is an HMAC, thre will be a response from Ming Pei on this issue going into more detail. =20 Philip =20 =20 ________________________________ From: David Dix [mailto:David.Dix@Cryptomathic.com]=20 Sent: Monday, March 09, 2009 3:41 PM To: Philip Hoyer Subject: Re: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt =20 Hi Philip,=20 I've taken a look at the spec and only have a couple of comments about the XML sample on page 19:=20 - The aes128-cbc encrypted cipher does not seem to be prepended with iv as it should be=20 - The padding of the plain data seems to be PKCS#7 format rather than ISO.=20 - The MAC is not applied to the encrypted fields but to the plain value. Regards=20 David Dix Cryptomathic Ltd. Direct: +44 (0)1223 225 355 Mobile: +44 (0)7747 665 540 David.Dix@Cryptomathic.com www.cryptomathic.com=20 From:=20 "Philip Hoyer" =20 To:=20 oath_technical@v2.listbox.com=20 Date:=20 24/02/2009 20:11=20 Subject:=20 [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt =20 ________________________________ Ladies and Gentlemen:=20 Could I invite the participants on the list please to review the PSKC spec as below as the work started in OATH and it would be great to see what you think of it now.=20 =20 Philip=20 =20 =20 ________________________________ From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org ] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Monday, February 23, 2009 12:14 PM To: KEYPROV Subject: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt=20 =20 Hi all,=20 this is a KEYPROV Working Group Last Call for comments on=20 http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-02.txt =20 Please send your comments to the list by March 6, 2009.=20 Ciao=20 Hannes & Phillip=20 ________________________________ oath_technical | Archives | Modify Your Subscription=20 =20 _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov =20 ------------------------------------------- oath_technical Archives: https://www.listbox.com/member/archive/1323/=3Dnow =20 RSS Feed: https://www.listbox.com/member/archive/rss/1323/ =20 Modify Your Subscription: https://www.listbox.com/member/?member_id=3D9641533&id_secret=3D130688982= -4c ef55 =20 Powered by Listbox: http://www.listbox.com =20 ------_=_NextPart_001_01C9A170.96C9D5B4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David,

Thanks for reviewing the = spec.

 

You are right the example is = incorrect.

 

The padding needs to be explicitly specified. In previous drafts and comments we agreed on PKCS#5 = padding.

 

The MAC is on the unencrypted value = since it is an HMAC, thre will be a response from Ming Pei on this issue going = into more detail.

 

Philip

 

 

From: David = Dix [mailto:David.Dix@Cryptomathic.com]
Sent: Monday, March 09, = 2009 3:41 PM
To: Philip Hoyer
Subject: Re: [OATH = Technical] FW: [KEYPROV] WGLC: = draft-ietf-keyprov-pskc-02.txt

 


Hi Philip,

I've taken a look at the spec and only have a couple of comments about the = XML sample on page 19:

- The aes128-cbc encrypted cipher does not seem to be prepended with iv as = it should be
- The padding of the plain data seems to be PKCS#7 format rather than ISO. =
- The MAC is not applied to the encrypted fields but to the plain = value.

Regards

David Dix

Cryptomathic Ltd.
Direct:   +44 (0)1223 225 355
Mobile: +44 (0)7747 665 540
David.Dix@Cryptomathic.com
www.cryptomathic.com

From:

"Philip Hoyer" <philip.hoyer@actividentity.com>

To:=

oath_technical@v2.listbox.com =

Date:

24/02/2009 20:11

Subject:

[OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt

 




Ladies and Gentlemen:
Could I invite the participants on the list please to = review the PSKC spec as below as the work started in OATH and it would be great = to see what you think of it now.
 
Philip
 

 


From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf= .org] On Behalf Of Tschofenig, Hannes = (NSN - FI/Espoo)
Sent: Monday, February 23, 2009 12:14 PM
To: KEYPROV
Subject: [KEYPROV] WGLC: = draft-ietf-keyprov-pskc-02.txt
 

Hi all,

this is a KEYPROV Working Group Last Call for comments = on
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-02.txt<= /span>

Please send your comments to the list by March 6, = 2009.

Ciao
Hannes & Phillip

oath_technical | Archives | Modify Your = Subscription


______________________________________________= _
KEYPROV mailing list
KEYPROV@ietf.org
https://www.ietf.org/mailman/listinfo/keyprov<= /span>


-------------------------------------------
oath_technical
Archives: https://www.listbox.com/member/archive/1323/=3D= now
RSS Feed: https://www.listbox.com/member/archive/rss/132= 3/
Modify Your Subscription: = https://www.listbox.com/member/?member_id=3D96= 41533&id_secret=3D130688982-4cef55
Powered by Listbox: = http://www.listbox.com<= o:p>

------_=_NextPart_001_01C9A170.96C9D5B4-- From philip.hoyer@actividentity.com Tue Mar 10 04:09:41 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EACE53A6CFA for ; Tue, 10 Mar 2009 04:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] 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 u1+EegiaG--7 for ; Tue, 10 Mar 2009 04:09:34 -0700 (PDT) Received: from frhub1.activcard.fr (frhub1.activcard.fr [91.151.120.133]) by core3.amsl.com (Postfix) with ESMTP id B2E1228C14B for ; Tue, 10 Mar 2009 04:09:33 -0700 (PDT) Received: from sur-corp-ex-02.corp.ad.activcard.com (sur-corp-ex-02.corp.ad.activcard.com [192.168.33.40]) by frhub1.activcard.fr (Postfix) with ESMTP id 605241838F1; Tue, 10 Mar 2009 12:10:08 +0100 (CET) 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_01C9A171.38763D85" Date: Tue, 10 Mar 2009 12:13:20 +0100 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB72C7@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <0FE70A085F9375408E93BF8409EB103D07209089@extlv102.eAladdin.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt Thread-Index: AcmVsDqj/B6j6zRKR2mQCtKzoVhkGwBC86RAAbU8oIAA9/WiQA== References: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB723A@sur-corp-ex-02.corp.ad.activcard.com> <0FE70A085F9375408E93BF8409EB103D07209089@extlv102.eAladdin.org> From: "Philip Hoyer" To: "Doron Cohen" Cc: oath_technical@v2.listbox.com, keyprov@ietf.org, Andrew Lindell Subject: Re: [KEYPROV] [OATH Technical] FW: WGLC: draft-ietf-keyprov-pskc-02.txt X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 11:09:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A171.38763D85 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Doron and Yehuda for your comments, =20 The MAC key issue (rightly spotted) is one of the few outstanding issues we wanted to discuss at the IETF meeting. =20 For the MAC on the unencrypted value Ming Pei is currently drafting a response to your comment. =20 Philip =20 ________________________________ From: Doron Cohen [mailto:doronc@aladdin.com]=20 Sent: Thursday, March 05, 2009 12:58 PM To: Philip Hoyer Cc: Andrew Lindell; oath_technical@v2.listbox.com Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt =20 Hi Philip, =20 Below are a couple of comments I received from Aladdin's Chief Cryptographer, Yehuda (Andrew) Lindell . Yehuda will be glad to provide more clarifications if required. =20 "When algorithms without integrity checks are used, such as AES-128-CBC, a keyed MAC value using the same key as the key encryption key MUST be placed in the element of the element. In this case the MAC algorithm type MUST be set in the element of the element. Implementations of PSKC MUST support HMAC-SHA1 (with the URI of http://www.w3.org/2000/09/xmldsig#hmac-sha1) as the mandatory-to-implement MAC algorithm. =20 [Yehuda Lindell] This is very bad practice. You should not use the same key for different tasks. The solution to this (where an authenticated-encryption scheme is not used) is to use key derivation to obtain two keys from the single one, and then use the first for encryption and the second for the MAC. =20 In section 4.2 the following appears: =20 Additionally, a element, which is populated with a MAC generated from the unencrypted value in case the encryption algorithm does not support integrity checks, MAY be included as a child element. The example shown at Figure 2 illustrates the usage of the element with two child elements, namely and . Both elements carry plaintext value within the child element. =20 [Yehuda Lindell] This says that the MAC is applied to the unencrypted value. This is bad practice (it is not always secure) and it's far better to generate the MAC by applying it to the encrypted ciphertext. In any case, this contradicts what appears below in Section 6.1 (Section 6.1 explicitly states that the MAC is applied to the encrypted value, which is the correct way to work). =20 =20 Best Regards Doron =20 Doron Cohen CTO, Authentication Business Unit Aladdin Knowledge Systems =20 =20 =20 =20 =20 =20 =20 From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Tuesday, February 24, 2009 22:14 To: oath_technical@v2.listbox.com Subject: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt =20 Ladies and Gentlemen: Could I invite the participants on the list please to review the PSKC spec as below as the work started in OATH and it would be great to see what you think of it now. =20 Philip =20 ________________________________ From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Monday, February 23, 2009 12:14 PM To: KEYPROV Subject: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt =20 Hi all,=20 this is a KEYPROV Working Group Last Call for comments on=20 http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-02.txt =20 Please send your comments to the list by March 6, 2009.=20 Ciao=20 Hannes & Phillip=20 ________________________________ oath_technical | Archives | Modify Your Subscription =20 =20 ************************************************************************ ************************** The contents of this email and any attachments are confidential. It is intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the=20 sender immediately and do not disclose the contents to anyone or make copies. ** eSafe scanned this email for viruses, vandals and malicious content ** ************************************************************************ ************************** ------_=_NextPart_001_01C9A171.38763D85 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WGLC: draft-ietf-keyprov-pskc-02.txt

Thanks Doron and Yehuda for your = comments,

 

The MAC key issue (rightly spotted) = is one of the few outstanding issues we wanted to discuss at the IETF = meeting.

 

For the MAC on the unencrypted = value Ming Pei is currently drafting a response to your = comment.

 

Philip

 

From: Doron = Cohen [mailto:doronc@aladdin.com]
Sent: Thursday, March 05, = 2009 12:58 PM
To: Philip Hoyer
Cc: Andrew Lindell; oath_technical@v2.listbox.com
Subject: RE: [OATH = Technical] FW: [KEYPROV] WGLC: = draft-ietf-keyprov-pskc-02.txt

 

Hi = Philip,

 <= /o:p>

Below are a = couple of comments I received from Aladdin’s Chief Cryptographer, Yehuda (Andrew) Lindell .   Yehuda will be glad to provide more clarifications if required.

 <= /o:p>

“When algorithms without integrity = checks are used, such as AES-128-CBC, a keyed MAC value using the same key as the = key encryption key MUST be placed in the <ValueMAC> element of the <Data> element.  In this case the MAC algorithm type MUST be = set in the <MACAlgorithm> element of the <KeyContainer> = element.  Implementations of PSKC MUST support HMAC-SHA1 (with the URI of http://www.w3.org/2000/09/xmldsig#hmac-sha1) as the = mandatory-to-implement MAC algorithm.

 

[Yehuda = Lindell] This is very bad practice. You should not use the same key for different = tasks. The solution to this (where an authenticated-encryption scheme is not = used) is to use key derivation to obtain two keys from the single one, and then = use the first for encryption and the second for the = MAC.

 <= /o:p>

In section = 4.2 the following appears:

 <= /o:p>

Additionally, a <ValueMac> element, =
which is populated with a MAC generated from the unencrypted value in =
case the encryption algorithm does not support integrity checks, MAY be =
included as a child element.  The example shown at Figure 2 =
illustrates the usage of the <Data> element with two child =
elements, namely <Secret> and <Counter>.  Both elements =
carry plaintext value within the <PlainValue> child =
element.

 <= /o:p>

[Yehuda = Lindell] This says that the MAC is applied to the unencrypted value. This is bad practice (it is not always secure) and it’s far better to generate = the MAC by applying it to the encrypted ciphertext. In any case, this = contradicts what appears below in Section 6.1 (Section 6.1 explicitly states that = the MAC is applied to the encrypted value, which is the correct way to = work).

 <= /o:p>

 <= /o:p>

Best = Regards

Doron

 <= /o:p>

Doron = Cohen

CTO, = Authentication Business Unit

Aladdin = Knowledge Systems

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

From: = Philip Hoyer [mailto:philip.hoyer@actividentity.com]
Sent: Tuesday, February = 24, 2009 22:14
To: = oath_technical@v2.listbox.com
Subject: [OATH Technical] = FW: [KEYPROV] WGLC: = draft-ietf-keyprov-pskc-02.txt

 

Ladies and = Gentlemen:

Could I invite the participants on = the list please to review the PSKC spec as below as the work started in OATH = and it would be great to see what you think of it = now.

 

Philip

 

From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Tschofenig, Hannes = (NSN - FI/Espoo)
Sent: Monday, February = 23, 2009 12:14 PM
To: KEYPROV
Subject: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt

 

Hi all,

this is a KEYPROV Working Group Last Call for comments = on
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-02.txt<= /span>

Please send your comments to the list by March 6, = 2009.

Ciao
Hannes & Phillip

oath_technica= l | Archives = = | Modify Your = Subscription

=

 


*************************************************************************= *************************
The contents of this email and any attachments are confidential.
It is intended for the named recipient(s) only.
If you have received this email in error please notify the system = manager or  the
sender immediately and do not disclose the contents to anyone or make = copies.
** eSafe scanned this email for viruses, vandals and malicious content = **
*************************************************************************= *************************

------_=_NextPart_001_01C9A171.38763D85-- From anders.rundgren@telia.com Mon Mar 16 01:19:34 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD69D3A6BCF for ; Mon, 16 Mar 2009 01:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SE=0.35] 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 PJDMKiskhunF for ; Mon, 16 Mar 2009 01:19:34 -0700 (PDT) Received: from mail.primekey.se (walter.primekey.se [195.149.137.135]) by core3.amsl.com (Postfix) with ESMTP id F0C113A69DA for ; Mon, 16 Mar 2009 01:19:33 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id 06A95C3C71; Mon, 16 Mar 2009 09:20:14 +0100 (CET) Message-ID: <49BE0BBD.8080902@telia.com> Date: Mon, 16 Mar 2009 09:20:13 +0100 From: Anders Rundgren User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: KEYPROV@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [KEYPROV] Use of ECC in 2-pass DSKPP X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 08:19:34 -0000 Dear list, Wrapping of downloaded secrets is extremely straightforward using RSA keys. It doesn't appear to be half as simple using ECC (ECDH?). Would it be possible to get a minimal extract showing how this is to be performed in DSKPP? Or is it not supported? This would be a problem since devices like routers are now being designed (on specification-level at least) to contain embedded ECC device keys. Anders From mpei@verisign.com Mon Mar 16 19:28:22 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFA713A6813 for ; Mon, 16 Mar 2009 19:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.714 X-Spam-Level: X-Spam-Status: No, score=-5.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 SDKKMdk6fEdv for ; Mon, 16 Mar 2009 19:28:12 -0700 (PDT) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id DF1B63A67A7 for ; Mon, 16 Mar 2009 19:28:12 -0700 (PDT) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n2H2SoAC015386; Mon, 16 Mar 2009 19:28:52 -0700 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Mar 2009 19:28:50 -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_01C9A6A8.1A9F67F9" Date: Mon, 16 Mar 2009 19:28:48 -0700 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C90126D881@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <065171DAC4F2674EA8C1142A1AF8E7C315467922@mou1wnexmb10.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt Thread-Index: AcmVsDqj/B6j6zRKR2mQCtKzoVhkGwBC86RAAbU8oIACRCn78AABZgJQAAAqJvA= References: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB723A@sur-corp-ex-02.corp.ad.activcard.com> <0FE70A085F9375408E93BF8409EB103D07209089@extlv102.eAladdin.org> <065171DAC4F2674EA8C1142A1AF8E7C315467921@mou1wnexmb10.vcorp.ad.vrsn.com> <065171DAC4F2674EA8C1142A1AF8E7C315467922@mou1wnexmb10.vcorp.ad.vrsn.com> From: "Pei, Mingliang" To: "Pei, Mingliang" , , X-OriginalArrivalTime: 17 Mar 2009 02:28:50.0695 (UTC) FILETIME=[1BBE6970:01C9A6A8] Cc: Andrew Lindell Subject: Re: [KEYPROV] [OATH Technical] FW: WGLC: draft-ietf-keyprov-pskc-02.txt X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 02:28:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A6A8.1A9F67F9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Copying keyprov mailing list... - Ming ________________________________ From: Pei, Mingliang=20 Sent: Monday, March 16, 2009 7:26 PM To: Pei, Mingliang; 'oath_technical@v2.listbox.com' Cc: 'Andrew Lindell' Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt =09 =09 I need to clarify that the strong hash is good when the cleartext to be encrypted is some long random secret bytes. If the value is within some known finite integer values, some simple hash lookup over all possible values will reveal the cleartext itself. =20 Thanks, =20 - Ming ________________________________ From: Pei, Mingliang=20 Sent: Monday, March 16, 2009 7:22 PM To: oath_technical@v2.listbox.com Cc: Andrew Lindell Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt =09 =09 Hi Doron and Andrew, =20 Thank you very much for the review and comments. =20 1. It is actually a working item in the draft per earlier comment. We agree with you that using the same key for MAC and encryption isn't a good practice. We thought of options that allow one to specify a separate MAC key by extending the current definition on the MAC algorithm type. Asking two keys isn't ideal for those pre-shared encryption key devices. In DSKPP, a MAC key was randomly generated and encrypted along with the secret. We have not had deep discussions on this. Thank you for raising the issue, and it will help us to make sure it is addressed in the final version. =20 2. The purpose of the ValueMAC is to serve integrity check of the data. It isn't intended for any sender authentication. On one hand, our initial version simply pass a hash value of the data to be encrypted, for example, ValueMAC =3D SHA_256(cleartext). Note that = hashing over ciphertext doesn't serve the purpose. A man-in-the-middle may alter the ciphertext and generate hash accordingly. Therefore it is necessary to calculate it over the cleartext.=20 =20 When HMAC was chosen for the integrity check purpose, we still felt that the hash over the original data was good. The essential argument goes back to the first item: should the MAC key be a separate one. If it is a separate one, the security concern doesn't seem to exist. =20 For simplicity, I consider that SHA_256(cleartext) is fine without requiring complexity in choosing MAC key for HMAC. Using the same key again isn't good. There are other ways to serve the integrity check, for example, encryption is over + . The simpliest is with a strong hash function such as SHA_256. I don't think a strong hash and encrypted value together will reveal the cleartext. =20 Suggestions are welcomed for making this choice. =20 Thank you, =20 - Ming ________________________________ From: Doron Cohen [mailto:doronc@aladdin.com]=20 Sent: Thursday, March 05, 2009 4:58 AM To: oath_technical@v2.listbox.com Cc: Andrew Lindell; oath_technical@v2.listbox.com Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt =09 =09 Hi Philip, =20 Below are a couple of comments I received from Aladdin's Chief Cryptographer, Yehuda (Andrew) Lindell . Yehuda will be glad to provide more clarifications if required. =20 "When algorithms without integrity checks are used, such as AES-128-CBC, a keyed MAC value using the same key as the key encryption key MUST be placed in the element of the element. In this case the MAC algorithm type MUST be set in the element of the element. Implementations of PSKC MUST support HMAC-SHA1 (with the URI of http://www.w3.org/2000/09/xmldsig#hmac-sha1) as the mandatory-to-implement MAC algorithm. =20 [Yehuda Lindell] This is very bad practice. You should not use the same key for different tasks. The solution to this (where an authenticated-encryption scheme is not used) is to use key derivation to obtain two keys from the single one, and then use the first for encryption and the second for the MAC. =20 In section 4.2 the following appears: =20 Additionally, a element, which is populated with a MAC generated from the unencrypted value in case the encryption algorithm does not support integrity checks, MAY be included as a child element. The example shown at Figure 2 illustrates the usage of the element with two child elements, namely and . Both elements carry plaintext value within the child element. =20 [Yehuda Lindell] This says that the MAC is applied to the unencrypted value. This is bad practice (it is not always secure) and it's far better to generate the MAC by applying it to the encrypted ciphertext. In any case, this contradicts what appears below in Section 6.1 (Section 6.1 explicitly states that the MAC is applied to the encrypted value, which is the correct way to work). =20 =20 Best Regards Doron =20 Doron Cohen CTO, Authentication Business Unit Aladdin Knowledge Systems =20 =20 =20 =20 =20 =20 =20 From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Tuesday, February 24, 2009 22:14 To: oath_technical@v2.listbox.com Subject: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt =20 Ladies and Gentlemen: Could I invite the participants on the list please to review the PSKC spec as below as the work started in OATH and it would be great to see what you think of it now. =20 Philip =20 ________________________________ From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Monday, February 23, 2009 12:14 PM To: KEYPROV Subject: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt =20 Hi all,=20 this is a KEYPROV Working Group Last Call for comments on=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-02.txt =20 Please send your comments to the list by March 6, 2009.=20 Ciao=20 Hannes & Phillip=20 ________________________________ oath_technical | Archives | Modify Your Subscription =20 =20 =09 ************************************************************************ ************************** The contents of this email and any attachments are confidential. It is intended for the named recipient(s) only. If you have received this email in error please notify the system manager or? the=20 sender immediately and do not disclose the contents to anyone or make copies. ** eSafe scanned this email for viruses, vandals and malicious content ** =09 ************************************************************************ ************************** =09 ________________________________ oath_technical | Archives | Modify Your Subscription =09 ------_=_NextPart_001_01C9A6A8.1A9F67F9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WGLC: = draft-ietf-keyprov-pskc-02.txt
Copying keyprov mailing list... -=20 Ming

From: Pei, Mingliang =
Sent: Monday,=20 March 16, 2009 7:26 PM
To: Pei, Mingliang;=20 'oath_technical@v2.listbox.com'
Cc: 'Andrew=20 Lindell'
Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC:=20 draft-ietf-keyprov-pskc-02.txt

I need to clarify that the strong hash is = good when=20 the cleartext to be encrypted is some long random secret bytes. If the = value=20 is within some known finite integer values, some simple hash lookup = over all=20 possible values will reveal the cleartext itself.
 
Thanks,
 
- Ming

From: Pei, Mingliang =
Sent:=20 Monday, March 16, 2009 7:22 PM
To:=20 oath_technical@v2.listbox.com
Cc: Andrew=20 Lindell
Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC:=20 draft-ietf-keyprov-pskc-02.txt

Hi Doron and Andrew,
 
Thank you very much for the review and=20 comments.
 
1. It is actually a working item in the = draft per=20 earlier comment. We agree with you that using the same key for MAC = and=20 encryption isn't a good practice. We thought of options that allow = one to=20 specify a separate MAC key by extending the current definition on = the MAC=20 algorithm type. Asking two keys isn't ideal for those = pre-shared=20 encryption key devices. In DSKPP, a MAC key was randomly generated = and=20 encrypted along with the secret. We have not had deep discussions on = this.=20 Thank you for raising the issue, and it will help us to make sure it = is=20 addressed in the final version.
 
2. The purpose of the ValueMAC is to serve = integrity=20 check of the data. It isn't intended for any sender authentication. = On one=20 hand, our initial version simply pass a hash value of the data to be = encrypted, for example, ValueMAC =3D SHA_256(cleartext). Note that = hashing=20 over ciphertext doesn't serve the purpose. A man-in-the-middle may = alter the=20 ciphertext and generate hash accordingly. Therefore it is necessary = to=20 calculate it over the cleartext.
 
When HMAC was chosen for the integrity = check purpose,=20 we still felt that the hash over the original data was good. The = essential=20 argument goes back to the first item: should the MAC key be a = separate one.=20 If it is a separate one, the security concern doesn't seem to=20 exist.
 
For simplicity, I consider that = SHA_256(cleartext) is=20 fine without requiring complexity in choosing MAC key for HMAC. = Using the=20 same key again isn't good. There are other ways to serve the = integrity=20 check, for example, encryption is over <cleartext> +=20 <Encrypted(random data) with the cleartext>. The simpliest is=20 <hash(cleartext)> with a strong hash function such as SHA_256. = I don't=20 think a strong hash and encrypted value together will reveal the=20 cleartext.
 
Suggestions are welcomed for making this=20 choice.
 
Thank you,
 
- Ming

From: Doron Cohen=20 [mailto:doronc@aladdin.com]
Sent: Thursday, March 05, = 2009 4:58=20 AM
To: oath_technical@v2.listbox.com
Cc: = Andrew=20 Lindell; oath_technical@v2.listbox.com
Subject: RE: = [OATH=20 Technical] FW: [KEYPROV] WGLC:=20 draft-ietf-keyprov-pskc-02.txt

Hi=20 Philip,

 

Below=20 are a couple of comments I received from Aladdin’s Chief = Cryptographer,=20 Yehuda (Andrew) Lindell .   Yehuda will be glad to = provide more=20 clarifications if required.

 

“When = algorithms=20 without integrity checks are used, such as AES-128-CBC, a keyed = MAC value=20 using the same key as the key encryption key MUST be placed in the = <ValueMAC> element of the <Data> element.  In = this case=20 the MAC algorithm type MUST be set in the <MACAlgorithm> = element of=20 the <KeyContainer> element.  Implementations of PSKC = MUST=20 support HMAC-SHA1 (with the URI of=20 http://www.w3.org/2000/09/xmldsig#hmac-sha1) as the = mandatory-to-implement=20 MAC algorithm.

 

[Yehuda=20 Lindell] This is very bad practice. You should not use the same = key for=20 different tasks. The solution to this (where an = authenticated-encryption=20 scheme is not used) is to use key derivation to obtain two keys = from the=20 single one, and then use the first for encryption and the second = for the=20 MAC.

 

In=20 section 4.2 the following appears:

 

Additionally, a =
<ValueMac> element, which is populated with a MAC generated from =
the unencrypted value in case the encryption algorithm does not support =
integrity checks, MAY be included as a child element.  The example =
shown at Figure 2 illustrates the usage of the <Data> element with =
two child elements, namely <Secret> and <Counter>.  =
Both elements carry plaintext value within the <PlainValue> child =
element.

 

[Yehuda=20 Lindell] This says that the MAC is applied to the unencrypted = value. This=20 is bad practice (it is not always secure) and it’s far = better to generate=20 the MAC by applying it to the encrypted ciphertext. In any case, = this=20 contradicts what appears below in Section 6.1 (Section 6.1 = explicitly=20 states that the MAC is applied to the encrypted value, which is = the=20 correct way to work).

 

 

Best=20 Regards

Doron

 

Doron=20 Cohen

CTO,=20 Authentication Business Unit

Aladdin=20 Knowledge Systems

 

 

 

 

 

 

 

From: = Philip Hoyer=20 [mailto:philip.hoyer@actividentity.com]
Sent: Tuesday, = February=20 24, 2009 22:14
To:=20 oath_technical@v2.listbox.com
Subject: [OATH Technical] = FW:=20 [KEYPROV] WGLC:=20 draft-ietf-keyprov-pskc-02.txt

 

Ladies=20 and Gentlemen:

Could=20 I invite the participants on the list please to review the PSKC = spec as=20 below as the work started in OATH and it would be great to see = what you=20 think of it now.

 

Philip

 

From:=20 keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On = Behalf Of=20 Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Monday, = February=20 23, 2009 12:14 PM
To: KEYPROV
Subject: = [KEYPROV] WGLC:=20 draft-ietf-keyprov-pskc-02.txt

 

Hi=20 all,

this is a=20 KEYPROV Working Group Last Call for comments on
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-02.txt<= /SPAN>=20

Please send=20 your comments to the list by March 6, 2009.

Ciao=20
Hannes=20 & Phillip

oath_technical=20 | Archives | Modify Your=20 Subscription

 


******************= *************************************************************************= *******
The=20 contents of this email and any attachments are confidential.
It = is=20 intended for the named recipient(s) only.
If you have received = this=20 email in error please notify the system manager or? the
sender = immediately and do not disclose the contents to anyone or make=20 copies.
** eSafe scanned this email for viruses, vandals and = malicious=20 content=20 = **
*******************************************************************= *******************************
oath_technical | Archives = | Modify=20 Your Subscription=20
------_=_NextPart_001_01C9A6A8.1A9F67F9-- From philip.hoyer@actividentity.com Tue Mar 17 08:11:46 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 268833A6B1D for ; Tue, 17 Mar 2009 08:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 KxlFF7IlNWO7 for ; Tue, 17 Mar 2009 08:11:45 -0700 (PDT) Received: from frhub1.activcard.fr (frhub1.activcard.fr [91.151.120.133]) by core3.amsl.com (Postfix) with ESMTP id 519723A69A2 for ; Tue, 17 Mar 2009 08:11:45 -0700 (PDT) Received: from sur-corp-ex-02.corp.ad.activcard.com (sur-corp-ex-02.corp.ad.activcard.com [192.168.33.40]) by frhub1.activcard.fr (Postfix) with ESMTP id 564CC183974; Tue, 17 Mar 2009 16:12:27 +0100 (CET) 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: Tue, 17 Mar 2009 16:15:44 +0100 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB7353@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <49BE0BBD.8080902@telia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Use of ECC in 2-pass DSKPP Thread-Index: AcmmEIKGkG56hzYlRv60sQE34DaOxAA/t+pA References: <49BE0BBD.8080902@telia.com> From: "Philip Hoyer" To: "Anders Rundgren" , Subject: Re: [KEYPROV] Use of ECC in 2-pass DSKPP X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 15:11:46 -0000 Anders, This was discussed but deferred as a future profile or extension. Since we are also waiting for the work from xmlenc group on the subject. Do you think this presents a problem? Philip -----Original Message----- From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Anders Rundgren Sent: Monday, March 16, 2009 8:20 AM To: KEYPROV@ietf.org Subject: [KEYPROV] Use of ECC in 2-pass DSKPP Dear list, Wrapping of downloaded secrets is extremely straightforward using RSA keys. It doesn't appear to be half as simple using ECC (ECDH?). Would it be possible to get a minimal extract showing how this is to be=20 performed in DSKPP? Or is it not supported? This would be a problem since devices like=20 routers are now being designed (on specification-level at least) to=20 contain embedded ECC device keys. Anders _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov From anders.rundgren@telia.com Tue Mar 17 12:44:08 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305593A685C for ; Tue, 17 Mar 2009 12:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.981 X-Spam-Level: X-Spam-Status: No, score=-0.981 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_20=-0.74] 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 lVPee9Xy+Jwx for ; Tue, 17 Mar 2009 12:44:07 -0700 (PDT) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by core3.amsl.com (Postfix) with ESMTP id CCA303A67FA for ; Tue, 17 Mar 2009 12:44:06 -0700 (PDT) Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C5034510C2; Tue, 17 Mar 2009 20:44:48 +0100 Message-ID: From: "Anders Rundgren" To: "Philip Hoyer" , References: <49BE0BBD.8080902@telia.com> <5BFE9E473DBFC24CA87F18F29B3F0AC403EB7353@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB7353@sur-corp-ex-02.corp.ad.activcard.com> Date: Tue, 17 Mar 2009 20:44:56 +0100 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 Windows Mail 6.0.6000.20661 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Subject: Re: [KEYPROV] Use of ECC in 2-pass DSKPP X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 19:44:08 -0000 Hi Philip, No, lack of ECC-support is probably not a problem at this stage. Based on my rather shallow knowledge of ECC it seems that it requires rather fundamental changes to symmetric-key provisioning protocols. It is though a bit disturbing that the W3C XML security guys haven't gotten further with NIST Suite B support. Anders ----- Original Message ----- From: "Philip Hoyer" To: "Anders Rundgren" ; Sent: Tuesday, March 17, 2009 16:15 Subject: RE: [KEYPROV] Use of ECC in 2-pass DSKPP Anders, This was discussed but deferred as a future profile or extension. Since we are also waiting for the work from xmlenc group on the subject. Do you think this presents a problem? Philip -----Original Message----- From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Anders Rundgren Sent: Monday, March 16, 2009 8:20 AM To: KEYPROV@ietf.org Subject: [KEYPROV] Use of ECC in 2-pass DSKPP Dear list, Wrapping of downloaded secrets is extremely straightforward using RSA keys. It doesn't appear to be half as simple using ECC (ECDH?). Would it be possible to get a minimal extract showing how this is to be performed in DSKPP? Or is it not supported? This would be a problem since devices like routers are now being designed (on specification-level at least) to contain embedded ECC device keys. Anders _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov From andrea.doherty@rsa.com Tue Mar 17 14:18:52 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01C4B3A6836 for ; Tue, 17 Mar 2009 14:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-4] 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 fydUdJMyIjEX for ; Tue, 17 Mar 2009 14:18:45 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id EF48D3A67FA for ; Tue, 17 Mar 2009 14:18:44 -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.2.5/Switch-3.1.7) with ESMTP id n2HLJPUQ002603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Mar 2009 17:19:26 -0400 (EDT) Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor) for ; Tue, 17 Mar 2009 17:19:18 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n2HLJI01021166 for ; Tue, 17 Mar 2009 17:19:18 -0400 Received: from CORPUSMX10B.corp.emc.com ([128.221.14.95]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Mar 2009 17:19:18 -0400 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_01C9A746.07A1610E" Date: Tue, 17 Mar 2009 17:19:13 -0400 Message-ID: <9ED76AB595E4944BB33D8998DE448D1104D0B2E4@CORPUSMX10B.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FPWD Transition Announcement - XML Security Specifications thread-index: AcmYPYezsyxZ3mZKRD+jT01WjSIDmADBYiXwAwCkHAA= From: To: X-OriginalArrivalTime: 17 Mar 2009 21:19:18.0374 (UTC) FILETIME=[0830E060:01C9A746] X-EMM-EM: Active Subject: [KEYPROV] FW: FPWD Transition Announcement - XML Security Specifications X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 21:18:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A746.07A1610E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, please take a look at the email that I forwarded below. =20 The "Derived Key" document is, among other things, intended to support KEYPROV - a "core" XML security way of having derived keys in ds:KeyInfo. Possibly for use in PSKC/DSKPP. =20 Andrea=20 =20 ________________________________ From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org] On Behalf Of Frederick Hirsch Sent: Thursday, February 26, 2009 1:09 PM To: chairs@w3.org; XMLSec WG Public List Cc: Frederick Hirsch Subject: FPWD Transition Announcement - XML Security Specifications =20 This is a First Public Working Draft transition announcement from the XML Security WG. =20 The following seven specifications have been published as First Public Working Drafts and the WG requests feedback on these documents. Comment may be sent to the list public-xmlsec-comments@w3.org . If possible please indicate the document in the subject line.=20 =20 (1) XML Signature Syntax and Processing Version 1.1 http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/ (2) XML Encryption Syntax and Processing Version 1.1 http://www.w3.org/TR/2009/WD-xmlenc-core1-20090226/ =20 (3) XML Signature Transform Simplification: Requirements and Design http://www.w3.org/TR/2009/WD-xmldsig-simplify-20090226/ =20 (4) XML Security Use Cases and Requirements http://www.w3.org/TR/2009/WD-xmlsec-reqs-20090226/ =20 (5) XML Security Derived Keys http://www.w3.org/TR/2009/WD-xmlsec-derivedkeys-20090226/ =20 (6) XML Signature Properties http://www.w3.org/TR/2009/WD-xmldsig-properties-20090226/ =20 (7) XML Security Algorithm Cross-Reference http://www.w3.org/TR/2009/WD-xmlsec-algorithms-20090226/ =20 These were included in the following transition request: http://lists.w3.org/Archives/Member/chairs/2009JanMar/0087.html =20 The Working Group has also published an updated working draft of Best Practices: =20 (8) XML Signature Best Practices W3C Working Draft 26 February 2009 http://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/ =20 The Working Group would appreciate review of these documents, with special attention to the algorithms listed in XML Signature 1.1 and XML Encryption 1.1, the proposed 2.0 changes in the Transform Simplification document and Use Cases and Requirements. Again, comment may be sent to the list public-xmlsec-comments@w3.org . =20 Thank you =20 regards, Frederick =20 Frederick Hirsch, Nokia Chair XML Security WG =20 =20 =20 ------_=_NextPart_001_01C9A746.07A1610E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All, please take a look at the email that I = forwarded=20 below.
 
The = “Derived Key”=20 document is, among other things, intended to support KEYPROV  – a “core” XML = security way of having=20 derived keys in ds:KeyInfo. Possibly for use in PSKC/DSKPP.

 

Andrea 

 

From:=20 public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org] = On Behalf Of Frederick = Hirsch
Sent: Thursday, February 26, 2009 = 1:09=20 PM
To: chairs@w3.org; = XMLSec WG=20 Public List
Cc: = Frederick=20 Hirsch
Subject: FPWD = Transition=20 Announcement - XML Security = Specifications

 

This is a First Public Working Draft = transition=20 announcement from the XML Security = WG.

 

The following seven specifications have been = published=20 as First Public Working Drafts and the WG requests feedback on these = documents.=20 Comment may be sent to the list public-xmlsec-comments@w3.o= rg .=20  If possible please indicate the document in the subject=20 line. 

  

(1) XML Signature Syntax and Processing = Version=20 1.1

http://www.= w3.org/TR/2009/WD-xmldsig-core1-20090226/


(2) XML=20 Encryption Syntax and Processing Version 1.1
 http://www.w= 3.org/TR/2009/WD-xmlenc-core1-20090226/

 

(3) XML Signature Transform = Simplification: Requirements and Design
http://w= ww.w3.org/TR/2009/WD-xmldsig-simplify-20090226/

 

(4) XML Security Use Cases and=20 Requirements
http://www.w3= .org/TR/2009/WD-xmlsec-reqs-20090226/

 

(5) XML Security Derived = Keys
http:/= /www.w3.org/TR/2009/WD-xmlsec-derivedkeys-20090226/

 

(6) XML Signature = Properties
http:/= /www.w3.org/TR/2009/WD-xmldsig-properties-20090226/

 

(7) XML Security Algorithm=20 Cross-Reference

http://= www.w3.org/TR/2009/WD-xmlsec-algorithms-20090226/

 

These were included in the following = transition=20 request:

= http://lists.w3.org/Archives/Member/chairs/2009JanMar/0087.html<= /o:p>

 

The Working Group has also published an = updated working=20 draft of Best Practices:

 

(8) XML Signature Best Practices W3C Working = Draft 26=20 February 2009
htt= p://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/<= /SPAN>

 

The Working Group would appreciate review of = these=20 documents, with special attention to the algorithms listed in XML = Signature 1.1=20 and XML Encryption 1.1, the proposed 2.0 changes in the Transform = Simplification=20 document and Use Cases and Requirements. Again, comment may be sent to = the=20 list public-xmlsec-comments@w3.org = .

 

Thank you

 

regards, Frederick

=

 

Frederick Hirsch,=20 Nokia

Chair XML Security = WG

 

 

 

------_=_NextPart_001_01C9A746.07A1610E-- From philip.hoyer@actividentity.com Thu Mar 19 07:20:27 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210253A6892 for ; Thu, 19 Mar 2009 07:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] 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 A8xzcYL+TNsq for ; Thu, 19 Mar 2009 07:20:21 -0700 (PDT) Received: from frhub1.activcard.fr (frhub1.activcard.fr [91.151.120.133]) by core3.amsl.com (Postfix) with ESMTP id 3D86D3A67FF for ; Thu, 19 Mar 2009 07:20:21 -0700 (PDT) Received: from sur-corp-ex-02.corp.ad.activcard.com (sur-corp-ex-02.corp.ad.activcard.com [192.168.33.40]) by frhub1.activcard.fr (Postfix) with ESMTP id 8BD6D18397A for ; Thu, 19 Mar 2009 15:21:05 +0100 (CET) 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_01C9A89D.ED834ADC" Date: Thu, 19 Mar 2009 15:21:00 +0100 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB738C@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <9ED76AB595E4944BB33D8998DE448D1104D0B2FC@CORPUSMX10B.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Keyprov call 17/03/09 meeting minutes Thread-Index: AcmnRaKz+YijQSTwQM2K46Fzn9esfAAATwxQAFWf8JA= References: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB7365@sur-corp-ex-02.corp.ad.activcard.com> <9ED76AB595E4944BB33D8998DE448D1104D0B2FC@CORPUSMX10B.corp.emc.com> From: "Philip Hoyer" To: Subject: [KEYPROV] Keyprov call 17/03/09 meeting minutes X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 14:20:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A89D.ED834ADC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attendees: Andrea, Phillip Hallam-Baker, Salah Machhani, Hannes Tschofenig =20 Andrea has reviewed the PSKC document and will post review to the list. =20 Andrea: Discussion around terminology, what is the best ways to deal with Pasi's comments. Hannes does not see the major issues in current terminology. Biggest unalignment is Keypackage in DSKPP is Key in PSKC. DeviceInfo is at level of KeyPackage, so Keypackage is DevicInfo and Key. What should we do about this? Will this block us going forward? =20 PSKC currently does not contain a reference to informational draft about profiles (for SecureID).. PHO this is an oversight and is missing =20 Ming: Issue about MAC, proposal from PHO, to make ContainerID mandatory and derive MAC key from it =20 ACTION: Ming to prepare some slides. =20 Philip Hoyer: what do we put on the slides for IETF 74? =20 Andrea: there are 3 Issues:=20 1) Are we at last call for PSKC? 2) DSKPP we need to review if we are getting close, we need reviewers 3) Alignment issues and informational draft. =20 PHB: =20 Since PSKC is last call there should be no internal issues.=20 We need to go through the comments on the list. Next steps to go to IETF last call, before we do that we need to declare that we believe that there are no issues. Maybe we raise informational draft at the PSKC discussion. =20 ACTION: PHB and Hannes, how to introduce information draft and how to present it in IETF meeting. =20 PHB: alignment issue should be put at the end since it might be a long discussion, hence better to have a separate presentation. =20 Presentation is Tuesday 3-6 California time. =20 Andrea: should we create a presentation about additional work as Pasi mentioned he could produce an informative RFC for alignment? Nobody was in favour to create another document.=20 =20 ACTION: Andrea to create a slide with your terminology PHO add some comments and then 2nd slide referring to comments received being few and hence our stance. =20 We will have a catch up meeting Friday morning 8:30 PST and PHO will send out meeting invite =20 =20 ________________________________ =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 117 Waterloo Road London SE1 8UL =20 Telephone: +44 (0) 20 7960 0220 Fax: +44 (0) 20 7902 1985 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_001_01C9A89D.ED834ADC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Attendees: Andrea, Phillip Hallam-Baker, Salah = Machhani, Hannes Tschofenig

 

Andrea has = reviewed the PSKC document and will post review to the = list.

 

Andrea: = Discussion around terminology, what is the best ways to deal with Pasi’s = comments. Hannes does not see the major issues in current = terminology.

  &nbs= p;         Biggest unalignment is Keypackage in DSKPP is Key in PSKC. DeviceInfo is = at level of KeyPackage, so Keypackage is DevicInfo and = Key.

  &nbs= p;         What should we do about this?

  &nbs= p;         Will this block us going forward?

 

  &nbs= p;         PSKC currently does not contain a reference to informational draft about = profiles (for SecureID).. PHO this is an oversight and is = missing

  &nbs= p;        

Ming:  = Issue about MAC, proposal from PHO, to make ContainerID mandatory and derive MAC key = from it

 

ACTION: Ming to = prepare some slides.

 

Philip Hoyer: = what do we put on the slides for IETF 74?

 

Andrea: there = are 3 Issues:

1) Are we at last call for = PSKC?

2) DSKPP we need to review if we are getting close, we need reviewers

3) Alignment issues and informational = draft.

 

PHB:  =  

Since PSKC is = last call there should be no internal issues.

We need to go = through the comments on the list.

Next steps to = go to IETF last call, before we do that we need to declare that we believe that = there are no issues.

Maybe we raise informational draft at the PSKC discussion.

 

ACTION: PHB and = Hannes, how to introduce information draft and how to present it in IETF = meeting.

 

PHB: alignment = issue should be put at the end since it might be a long discussion, hence = better to have a separate presentation.

 

Presentation is = Tuesday 3-6 California time.

 

Andrea: should = we create a presentation about additional work as Pasi mentioned he could produce = an informative RFC for alignment? Nobody was in favour to create another = document.

 

ACTION: Andrea = to create a slide with your terminology PHO add some comments and then = 2nd slide referring to comments received being few and hence our = stance.

 

We will have a = catch up meeting Friday morning 8:30 PST and PHO will send out meeting = invite

 

 

________________________________

 

Philip Hoyer

 

Senior Architect - Office of CTO

 

ActivIdentity (UK)=

117 Waterloo = Road

London SE1 8UL

 

Telephone: +44 (0) 20 7960 0220

Fax: +44 (0) 20 7902 1985

 

Private and confidential: This message and any attachments may = contain

privileged / confidential information. If you are not an intended = recipient,

you must not copy, distribute, discuss or take any action in reliance on = it.

If you have received this communication in error, please notify the = sender

and delete this message immediately.

 

------_=_NextPart_001_01C9A89D.ED834ADC-- From anders.rundgren@telia.com Thu Mar 19 08:37:46 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE99E28C141 for ; Thu, 19 Mar 2009 08:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, HELO_EQ_SE=0.35] 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 TuSl4BW4a+x1 for ; Thu, 19 Mar 2009 08:37:46 -0700 (PDT) Received: from mail.primekey.se (walter.primekey.se [195.149.137.135]) by core3.amsl.com (Postfix) with ESMTP id 5CE7128C147 for ; Thu, 19 Mar 2009 08:37:44 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id B3EF3C3E47; Thu, 19 Mar 2009 16:38:27 +0100 (CET) Message-ID: <49C266F3.5040604@telia.com> Date: Thu, 19 Mar 2009 16:38:27 +0100 From: Anders Rundgren User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: KEYPROV@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [KEYPROV] Securing PIN policies - From provisioning to enforcement X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 15:37:46 -0000 For those of you guys who are slightly research-oriented, the following may be of some interest... :-) Somebody told me that specifying things like PIN policies in a provisioning protocol was a bad idea since the client-could do whatever it wanted with this information, including ignoring it. However, after thinking a bit about this glaring wart for a while, I believe that this is yet another area where external key MAC schemes excel because you could make (locally enforceable NB) issuer policy information a part of a key integrity MAC as well. Assume that the issuer has specified a PIN min-length you could have a key-import API like the following: importKey (,, , ) Properly designed, the API should reject a tampered-with PIN policy as well as a user-defined PIN that doesn't match the policy. I don't intend to add this scheme to KeyGen2 because KeyGen2 ties general-purpose credential policies to attested key-pairs instead of MACs which is more powerful since policy violations are detected already during the issuance process rather than leaving the user with a potentially half-provisioned, non-working token. The idea behind this is creating a "smarter smart card" which together with embedded device certificates, could be technically quite secure to provision in the field using computers not configured (or known) by the issuing organization which have several important use-cases: - consumers - employees who are outside of the organization's regular domain and desperately need a replacement card - mobile devices using built-in crypto HW Anders R From mpei@verisign.com Fri Mar 20 16:16:38 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A553A6AC9 for ; Fri, 20 Mar 2009 16:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.856 X-Spam-Level: X-Spam-Status: No, score=-5.856 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-4] 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 yDH4xr8zCA1k for ; Fri, 20 Mar 2009 16:16:31 -0700 (PDT) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 4037D3A6BBE for ; Fri, 20 Mar 2009 16:16:31 -0700 (PDT) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n2KNHIRS006544; Fri, 20 Mar 2009 16:17:18 -0700 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Mar 2009 16:17:17 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A9B2.02F0B97D" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 20 Mar 2009 16:17:17 -0700 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C90126D9F0@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <9ED76AB595E4944BB33D8998DE448D1104D0B2E4@CORPUSMX10B.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] FW: FPWD Transition Announcement - XML SecuritySpecifications Thread-Index: AcmYPYezsyxZ3mZKRD+jT01WjSIDmADBYiXwAwCkHAAAmr8zsA== References: <9ED76AB595E4944BB33D8998DE448D1104D0B2E4@CORPUSMX10B.corp.emc.com> From: "Pei, Mingliang" To: , X-OriginalArrivalTime: 20 Mar 2009 23:17:17.0853 (UTC) FILETIME=[0320E4D0:01C9A9B2] Cc: Magnus.Nystrom@rsa.com Subject: Re: [KEYPROV] FW: FPWD Transition Announcement - XML SecuritySpecifications X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 23:16:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A9B2.02F0B97D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the forwarding. The DerviedKey looks to be a common definition. In particular, the example in 7.1 looks so similar to what we have in PSKC for PBE derived key. The only difference is that PSKC used "CarrierName" and the xmlsec-derivedkeys used "MasterKeyName". It seems to be naturally aligned - both referring to PKCS#5 XML definition. =20 XMLSEC-DerivedKeys Df3dRAhjGh8=3D 2000 16 Our shared secret =09 PSKC Passphrase1 "> Ej7/PEpyEpw=3D 1000 16 - Ming ________________________________ From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of andrea.doherty@rsa.com Sent: Tuesday, March 17, 2009 2:19 PM To: keyprov@ietf.org Subject: [KEYPROV] FW: FPWD Transition Announcement - XML SecuritySpecifications =09 =09 All, please take a look at the email that I forwarded below. =20 The "Derived Key" document is, among other things, intended to support KEYPROV - a "core" XML security way of having derived keys in ds:KeyInfo. Possibly for use in PSKC/DSKPP. =20 Andrea=20 =20 =09 ________________________________ From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org] On Behalf Of Frederick Hirsch Sent: Thursday, February 26, 2009 1:09 PM To: chairs@w3.org; XMLSec WG Public List Cc: Frederick Hirsch Subject: FPWD Transition Announcement - XML Security Specifications =20 This is a First Public Working Draft transition announcement from the XML Security WG. =20 The following seven specifications have been published as First Public Working Drafts and the WG requests feedback on these documents. Comment may be sent to the list public-xmlsec-comments@w3.org . If possible please indicate the document in the subject line.=20 =20 (1) XML Signature Syntax and Processing Version 1.1 http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/ =09 (2) XML Encryption Syntax and Processing Version 1.1 http://www.w3.org/TR/2009/WD-xmlenc-core1-20090226/ =20 (3) XML Signature Transform Simplification: Requirements and Design http://www.w3.org/TR/2009/WD-xmldsig-simplify-20090226/ =20 (4) XML Security Use Cases and Requirements http://www.w3.org/TR/2009/WD-xmlsec-reqs-20090226/ =20 (5) XML Security Derived Keys http://www.w3.org/TR/2009/WD-xmlsec-derivedkeys-20090226/ =20 (6) XML Signature Properties http://www.w3.org/TR/2009/WD-xmldsig-properties-20090226/ =20 (7) XML Security Algorithm Cross-Reference http://www.w3.org/TR/2009/WD-xmlsec-algorithms-20090226/ =20 These were included in the following transition request: http://lists.w3.org/Archives/Member/chairs/2009JanMar/0087.html =20 The Working Group has also published an updated working draft of Best Practices: =20 (8) XML Signature Best Practices W3C Working Draft 26 February 2009 http://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/ =20 The Working Group would appreciate review of these documents, with special attention to the algorithms listed in XML Signature 1.1 and XML Encryption 1.1, the proposed 2.0 changes in the Transform Simplification document and Use Cases and Requirements. Again, comment may be sent to the list public-xmlsec-comments@w3.org . =20 Thank you =20 regards, Frederick =20 Frederick Hirsch, Nokia Chair XML Security WG =20 =20 =20 ------_=_NextPart_001_01C9A9B2.02F0B97D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks for the forwarding. The DerviedKey looks = to be a=20 common definition. In particular, the example in 7.1 looks so similar to = what we=20 have in PSKC for PBE derived key. The only difference is that PSKC used=20 "CarrierName" and the xmlsec-derivedkeys used "MasterKeyName". = It=20 seems to be naturally aligned - both referring to PKCS#5 XML=20 definition.
 
XMLSEC-DerivedKeys
<dkey:DerivedKey
   xmlns:dkey=3D"http://www.w3.org/2009/01/xmlsec-derived-key"
   xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xenc=3D"http://www.w3.org/2001/04/xmlenc#"
   =
xmlns:pkcs-5=3D"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-=
0#">
   <dkey:KeyDerivationMethod=20
       =
Algorithm=3D"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf=
2">
     <pkcs-5:PBKDF2-params>
       <Salt>
         <Specified>Df3dRAhjGh8=3D</Specified>
       </Salt>
       <IterationCount>2000</IterationCount>
       <KeyLength>16</KeyLength>
       <PRF/>
     </pkcs-5:PBKDF2-params>
   </dkey:KeyDerivationMethod>
   <xenc:ReferenceList>
     <xenc:DataReference URI=3D"#ED"/>
   </xenc:ReferenceList>
   <MasterKeyName>Our shared =
secret</MasterKeyName>
</dkey:DerivedKey>

PSKC
<DerivedKey>
  <CarriedKeyName>Passphrase1</CarriedKeyName>
  <KeyDerivat=
ionMethod
    Algorithm=3D"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf=
2">
    <pkcs5:PBKDF2-params>
=
      <pkcs5:Salt>
  &nb=
sp;    =
 <pkcs5:Specified>Ej7/PEpyEpw=3D</pkcs5:Specified>=
;
      </pkcs5:Salt>
 &nb=
sp;    <pkcs5:IterationCount>1000</pkcs5:Ite=
rationCount>
      <pkcs5:KeyLengt=
h>16</pkcs5:KeyLength>
      &l=
t;pkcs5:PRF/>
    </pkcs5:PBKDF2-params><=
BR>   </KeyDerivationMethod>
   &l=
t;xenc:ReferenceList>
    <xenc:DataReference =
URI=3D"#ED"/>
   </xenc:ReferenceList>
<=
/DerivedKey>
- Ming
From: keyprov-bounces@ietf.org=20 [mailto:keyprov-bounces@ietf.org] On Behalf Of=20 andrea.doherty@rsa.com
Sent: Tuesday, March 17, 2009 = 2:19=20 PM
To: keyprov@ietf.org
Subject: [KEYPROV] FW: = FPWD=20 Transition Announcement - XML = SecuritySpecifications

All, please take a look at the email that I = forwarded=20 below.
 
The = “Derived Key”=20 document is, among other things, intended to support KEYPROV  – a “core” = XML security way of having=20 derived keys in ds:KeyInfo. Possibly for use in PSKC/DSKPP.

 

Andrea 

 

From:=20 public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org] = On Behalf Of Frederick = Hirsch
Sent: Thursday, February 26, = 2009 1:09=20 PM
To: = chairs@w3.org; XMLSec=20 WG Public List
Cc: = Frederick=20 Hirsch
Subject: = FPWD=20 Transition Announcement - XML Security=20 Specifications

 

This is a First Public Working Draft = transition=20 announcement from the XML Security = WG.

 

The following seven specifications have been = published=20 as First Public Working Drafts and the WG requests feedback on these=20 documents. Comment may be sent to the list public-xmlsec-comments@w3.o= rg=20 .  If possible please indicate the document in the subject=20 line. 

  

(1) XML Signature Syntax and Processing = Version=20 1.1

http://www.= w3.org/TR/2009/WD-xmldsig-core1-20090226/


(2)=20 XML Encryption Syntax and Processing Version 1.1
 http://www.w= 3.org/TR/2009/WD-xmlenc-core1-20090226/

 

(3) XML Signature = Transform=20 Simplification: Requirements and Design
http://w= ww.w3.org/TR/2009/WD-xmldsig-simplify-20090226/

 

(4) XML Security Use Cases and = Requirements
http://www.w3= .org/TR/2009/WD-xmlsec-reqs-20090226/

 

(5) XML Security Derived = Keys
http:/= /www.w3.org/TR/2009/WD-xmlsec-derivedkeys-20090226/

 

(6) XML Signature = Properties
http:/= /www.w3.org/TR/2009/WD-xmldsig-properties-20090226/

 

(7) XML Security Algorithm=20 Cross-Reference

http://= www.w3.org/TR/2009/WD-xmlsec-algorithms-20090226/

 

These were included in the following = transition=20 request:

= http://lists.w3.org/Archives/Member/chairs/2009JanMar/0087.html<= /o:p>

 

The Working Group has also published an = updated=20 working draft of Best Practices:

 

(8) XML Signature Best Practices W3C Working = Draft 26=20 February 2009
htt= p://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/<= /SPAN>

 

The Working Group would appreciate review of = these=20 documents, with special attention to the algorithms listed in XML = Signature=20 1.1 and XML Encryption 1.1, the proposed 2.0 changes in the Transform=20 Simplification document and Use Cases and Requirements. Again, comment = may be=20 sent to the list public-xmlsec-comments@w3.org=20 .

 

Thank you

 

regards, Frederick

=

 

Frederick Hirsch,=20 Nokia

Chair XML Security=20 WG

 

 

 

= ------_=_NextPart_001_01C9A9B2.02F0B97D-- From andrea.doherty@rsa.com Sun Mar 22 19:08:29 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1823A680E for ; Sun, 22 Mar 2009 19:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.424 X-Spam-Level: X-Spam-Status: No, score=-5.424 tagged_above=-999 required=5 tests=[AWL=-1.025, BAYES_00=-2.599, J_BACKHAIR_33=1, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] 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 5rt8IwKRpUiC for ; Sun, 22 Mar 2009 19:08:28 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id CB6F53A6993 for ; Sun, 22 Mar 2009 19:08:27 -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.2.5/Switch-3.1.7) with ESMTP id n2N29C8x015824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Mar 2009 22:09:13 -0400 (EDT) Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Sun, 22 Mar 2009 22:09:05 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n2N292vL006604; Sun, 22 Mar 2009 22:09:04 -0400 Received: from CORPUSMX10B.corp.emc.com ([128.221.14.95]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Mar 2009 22:09:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9AB5C.558B8C2D" Date: Sun, 22 Mar 2009 22:06:36 -0400 Message-ID: <9ED76AB595E4944BB33D8998DE448D1102BACAE6@CORPUSMX10B.corp.emc.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: WGLC: draft-ietf-keyprov-pskc-02.txt Thread-Index: AcmVsDqj/B6j6zRKR2mQCtKzoVhkGwVq8R6d References: <3D3C75174CB95F42AD6BCC56E5555B450112E474@FIESEXC015.nsn-intra.net> From: To: , X-OriginalArrivalTime: 23 Mar 2009 02:09:03.0233 (UTC) FILETIME=[56709710:01C9AB5C] X-EMM-EM: Active Subject: Re: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 02:08:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AB5C.558B8C2D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Attached please find my comments to the below-referenced PSKC I-D. ________________________________ From: keyprov-bounces@ietf.org on behalf of Tschofenig, Hannes (NSN - = FI/Espoo) Sent: Mon 2/23/2009 7:14 AM To: KEYPROV Subject: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt Hi all,=20 this is a KEYPROV Working Group Last Call for comments on=20 http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-02.txt = =20 Please send your comments to the list by March 6, 2009.=20 Ciao=20 Hannes & Phillip=20 ------_=_NextPart_001_01C9AB5C.558B8C2D Content-Type: text/plain; name="pskc-02-aed-comments.txt" Content-Transfer-Encoding: base64 Content-Description: pskc-02-aed-comments.txt Content-Disposition: attachment; filename="pskc-02-aed-comments.txt" TmljZSB3b3JrISAgUGxlYXNlIHNlZSBteSBjb21tZW50cyBiZWxvdy4NCg0KS0VZDQo9PT0NClMg PSBTZWN0aW9uDQpQID0gUGFyYWdyYXBoDQpGID0gRmlndXJlDQpeXnRleHReXiA9IEluc2VydCBu ZXcgdGV4dA0KWFh0ZXh0WFggPSBEZWxldGUgb2xkIHRleHQNCiYmbmV3X3RleHQmJiA9IFJlcGxh Y2UgdGV4dCB3aXRoIG5ld190ZXh0DQowMDAgPSBtaXNzaW5nIHRleHQNCg0KQ09NTUVOVFMNCj09 PT09PT09DQoNCkNvbnRlbnQ6DQotLS0tLS0tLQ0KMS4gRjEgYW5kIFM0IC0gVGhlIGVudGl0aWVz IGluIHRoZSBmaWd1cmUgZG8gbm90IGZ1bGx5IG1hcCB0byB0aGUgY29udGVudCBpbiBTNC4NCg0K ICAgTWFwIG9mIEYxLT5TNDoNCg0KICAgICBLZXlDb250YWluZXItPktleUNvbnRhaW5lciB8IE9L DQoNCiAgICAgRW5jcnlwdGlvbktleS0+MDAwIHwgTUlTU0lORyBURVhUIChpdCdzIGFsc28gbm90 IHNob3duIGluIHRoZSBleGFtcGxlKQ0KDQogICAgIFNpZ25hdHVyZS0+MDAwIHwgTUlTU0lORyBU RVhUIChpdCdzIGFsc28gbm90IHNob3duIGluIHRoZSBleGFtcGxlKQ0KDQogICAgIERldmljZS0+ MDAwIHwgTUlTU0lORyBURVhUDQoNCiAgICAgVXNlci0+UzQuMyB8IElzIHRoZSB0ZXh0IGFzc29j aWF0ZWQgd2l0aCBEZXZpY2U6OlVzZXIgb3IgS2V5OjpVc2VySUQ/DQoNCiAgICAgRGV2aWNlSW5m by0+UzQuMSB8IE9LDQoNCiAgICAgU2VyaWFsTnVtYmVyLT5TNC4xIHwgT0sNCg0KICAgICBNYW51 ZmFjdHVyZXItPlM0LjEgfCBPSw0KDQogICAgIEtleS0+UzQuMiB8IE9LDQoNCiAgICAgSUQtPlM0 LjIgYXMgS2V5SUQgfCBURVhUIEFORCBGSUdVUkUgRE8gTk9UIE1BVENIDQoNCiAgICAgQWxnb3Jp dGhtLT5TNC4yIGFzIEtleUFsZ29yaXRobSB8IFRFWFQgQU5EIEZJR1VSRSBETyBOT1QgTUFUQ0gN Cg0KICAgICBVc2VyLT5TNC4zIHwgVVNFUiBJUyBOT1QgQU4gRUxFTUVOVCBPRiBLRVk7IFVTRVJJ RCBJUy4gDQoNCiAgICAgMDAwPC1TNC40IHwgVVNBR0UgTk9UIFNIT1dOIElOIEZJR1VSRS4NCiAg ICAgICAgICAgICAgICAgUkVDT01NRU5EQVRJT046IFJFUExBQ0UgS0VZOlVTRVIgV0lUSCBLRVk6 VVNBR0UgSU4gRjENCg0KICAgICBLZXlEYXRhLT5YWFggfCBNSVNTSU5HIFRFWFQNCg0KMi4gUzQu MSwgPERldmljZUJpbmRpbmc+OiBUaGUgZGVmaW5pdGlvbiBvZiA8RGV2aWNlQmluZGluZz4gcmVx dWlyZXMgYmV0dGVyIGNsYXJpZmljYXRpb24sIGFzIGl0IHNlZW1zIHRvIGdldCBsb3N0IGluIHRo aXMgcGFyYWdyYXBoLiAgQ29uc2lkZXIgcmV3b3JkaW5nIHRvOiANCiAgICJUaGlzIGVsZW1lbnQg YWxsb3dzIGEgcHJvdmlzaW9uaW5nIHNlcnZlciB0byBlbnN1cmUgdGhhdCB0aGUga2V5IGlzDQog ICAgZ29pbmcgdG8gYmUgbG9hZGVkIGludG8gdGhlIGRldmljZSBmb3Igd2hpY2ggdGhlIGtleSBw cm92aXNpb25pbmcNCiAgICByZXF1ZXN0IHdhcyBhcHByb3ZlZC4gVGhlIGRldmljZSBpcyBib3Vu ZCB0byB0aGUgcmVxdWVzdCB1c2luZyBhIGRldmljZQ0KICAgIGlkZW50aWZpZXIsIGUuZy4sIGFu IElNRUkgZm9yIHRoZSBwaG9uZSwgb3IgYW4gaWRlbnRpZmllciBmb3IgYSBjbGFzcyBvZg0KICAg IGlkZW50aWZpZXJzLCBlLmcuLCB0aG9zZSBmb3Igd2hpY2ggdGhlIGtleXMgYXJlIHByb3RlY3Rl ZCBieSBhIFRQTS4iIA0KDQozLiBTNC4yLCA8S2V5QWxnb3JpdGhtPiAtIEluc3RlYWQgb2YgcmVm ZXJlbmNpbmcgc2VjdGlvbiAxMCAoYSBmb3J3YXJkIHJlZmVyZW5jZSksIGl0IHdvdWxkIGJlIGJl dHRlciB0byByZWZlcmVuY2UgdGhlIEktRCBkcmFmdC1ob3llci1rZXlwcm92LXBza2MtYWxnb3Jp dGhtLXByb2ZpbGVzLTAwLnR4dC4NCg0KNC4gUzQuMiwgPFVzYWdlPiAtIFRoZSBpbXBsaWNhdGlv biBvZiB0aGUgdGV4dCBpcyB0aGF0IDxVc2FnZT4gcGVydGFpbnMgb25seSB0byBPVFAuICBJcyB0 aGlzIGNvcnJlY3Q/ICBXaGF0IGlmIHNvbWUgb3RoZXIgYXBwbGljYXRpb24gYWxzbyByZXF1aXJl cyAic3VwcGxlbWVudGFyeSB1c2FnZSBpbmZvcm1hdGlvbiI/ICBQZXJoYXBzICJPVFAgYW5kIENS IGFsZ29yaXRobXMiIHNob3VsZCBiZSBtZW50aW9uZWQgYXMgZXhhbXBsZXMuDQoNCjUuIFM0LjIs IDxEYXRhPiAtIDxDb3VudGVyPiwgPFRpbWU+LCA8VGltZUludGVydmFsPiwgYW5kIDxUaW1lRHJp ZnQ+IGFyZSBPVFAtYmFzZWQgYXR0cmlidXRlcywgZGlmZmVyZW50aWF0ZWQgZnJvbSA8U2VjcmV0 Pi4gIFBlcmhhcHMgZGVzY3JpYmUgaG93IDxTZWNyZXQ+IGlzIGRpZmZlcmVudGlhdGVkIGZyb20g dGhlc2Ugb3RoZXIgYXR0cmlidXRlcy4NCg0KNi4gUzYsIHRpdGxlIC0gIjYuICBQcm90ZWN0aW9u IG9mIEtleXMgYW5kIFJlbGF0ZWQgRGF0YSIgLSAiUmVsYXRlZCBEYXRhIG9ubHkgc2VlbXMgdG8g cGVydGFpbiB0byBTNi40ICJUcmFuc21pc3Npb24gb2YgS2V5IERlcml2YXRpb24gVmFsdWVzIiwg d2hpY2ggaXRzZWxmIG9ubHkgc2VlbXMgdG8gcGVydGFpbiB0byBNYXN0ZXJDYXJkJ3MgQ0FQIEtl eVByb2ZpbGVJRC4gIERTS1BQIGhhcyBhIGRpcmVjdCBkZXBlbmRlbmNlIG9uIFM2LjEgLSBTNi4z IGluIHRoYXQgdGhlc2Ugc2VjdGlvbnMgZGVzY3JpYmUgdGhlIEtleSBQcm90ZWN0aW9uIE1ldGhv ZHMgdGhhdCBhcmUgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBpbiBEU0tQUC4gIEZyb20gYSBEU0tQ UCBpbXBsZW1lbnRhdGlvbiBwb2ludCBvZiB2aWV3LCBTNi40IGNyZWF0ZXMgY29uZnVzaW9uLiAg QXMgYW4gaW1wbGVtZW50ZXIgb2YgRFNLUFAsIEkgd291bGQgd2FudCB0byBrbm93IHdoYXQgbWV0 aG9kcyBJIGNhbiB1c2UgdG8gcHJvdGVjdCB0aGUga2V5IHRoYXQgSSBhbSBwcm92aXNpb25pbmcu ICBIb3cga2V5cyB1c2VkIHRvIGRlcml2ZSBhIGtleSB1c2VkIHRvIHByb3RlY3QgdGhlIHBheWxv YWQgd2FzIHRyYW5zbWl0dGVkIGJlbG9uZyBpbiBhIGRpZmZlcmVudCBzZWN0aW9uLCBzdWNoIGFz IHdhcyBkb25lIHdpdGggRGlnaXRhbCBTaWduYXR1cmVzIChTNykuICBBcyBzdWNoLCBJIHdvdWxk IG1vdmUgUzYuNCB0byBTNCAob3IgaXRzIG93biBTZWN0aW9uKSBhbmQgcmVuYW1lIFM2IHRvICJL ZXkgUHJvdGVjdGlvbiBNZXRob2RzIiAodG8gY3JlYXRlIHN0cm9uZ2VyIGFsaWdubWVudCB3aXRo IERTS1BQKS4NCg0KNy4gUzYuMSAtIFM2LjMgLSBUT0RPOiBWZXJpZnkgdGhhdCB0aGUgd2F5IGlu IHdoaWNoIHRoZXNlIG1ldGhvZHMgYXJlIGRlZmluZWQgc2F0aXNmaWVzIHRoZSBtYW5kYXRvcnkt dG8taW1wbGVtZW50IEtleSBQcm90ZWN0aW9uIE1ldGhvZHMgc3BlY2lmaWVkIGluIERTS1BQLg0K DQo4LiBTNi4yLCBJdGVyYXRpb24gQ291bnQgb2YgMTAwMCAtIFRPRE86IFZlcmlmeSB0aGF0IHRo aXMgaXMgaGlnaCBlbm91Z2ggZm9yIERTS1BQLg0KDQo5LiBTOSwgIk5ldyBQU0tDIEFsZ29yaXRo bSBQcm9maWxlcyIgLSBUbyBhdm9pZCBmb3J3YXJkIHJlZmVyZW5jZXMsIGl0IHdvdWxkIGJlIGJl dHRlciB0byByZWZlcmVuY2UgdGhlIEktRCBkcmFmdC1ob3llci1rZXlwcm92LXBza2MtYWxnb3Jp dGhtLXByb2ZpbGVzLTAwLnR4dC4NCg0KMTAuIFMxMi41IC0gTk9URTogVGhlcmUgaXMgbm8gY29y cmVzcG9uZGluZyBEU0tQUCBWZXJzaW9uIFJlZ2lzdHJ5LiAgVE9ETzogVmVyaWZ5IHdoZXRoZXIg b25lIGlzIHJlcXVpcmVkLg0KDQoxMS4gUzEzLjEgLSBXaHkgaXMgdGhlcmUgYSByZWZlcmVuY2Ug dG8gM0RFUy4gIENvbnNpZGVyIHJlLXdvcmtpbmcvdXBkYXRpbmcgdGhpcyBzZWN0aW9uLg0KDQoN ClRlcm1pbm9sb2d5IE1pcy1BbGlnbm1lbnQgd2l0aCBEU0tQUDoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCjEuIFdoaWxlIERTS1BQIHdhcyBnZW5lcmFsaXplZCB0byBh bnkgdHlwZSBvZiBzeW1tZXRyaWMta2V5IGJhc2VkIGFwcGxpY2F0aW9uLCBQU0tDIGlzIGdlYXJl ZCB0byBhdXRoZW50aWNhdGlvbiBzeXN0ZW1zLCBlc3AuIE9UUCBhdXRoZW50aWNhdGlvbiBzeXN0 ZW0uICBSZWZlciB0byB0aGUgZm9sbG93aW5nIGV4YW1wbGVzOg0KDQogICAqIFMxLjAgLSAiYXV0 aGVudGljYXRpb24gc3lzdGVtcyIsICJhdXRoZW50aWNhdGlvbiBzZXJ2ZXIiDQoNCjIuIERTS1BQ J3MgPEtleVBhY2thZ2U+IGxvZ2ljYWxseSBpbmNsdWRlcyA8RGV2aWNlPiBhbmQgPEtleT4uICBJ biBmYWN0LCBEU0tQUCdzIDxLZXlQYWNrYWdlPiBtYXBzIHRvIFBTS0MncyA8S2V5Q29udGFpbmVy PiB3aXRoIHRoZSBvbmUgZXhjZXB0aW9uIHRoYXQgUFNLQydzIDxLZXlDb250YWluZXI+IHN1cHBv cnRzIG11bHRpcGxlIGtleXMsIHdoZXJlYXMgRFNLUFAgb25seSBzdXBwb3J0cyBvbmUuICBTbywg aW4gZXNzZW5jZSBQU0tDJ3MgPEtleUNvbnRhaW5lcj4gaXMgYSBjb2xsZWN0aW9uIG9mIDxLZXlQ YWNrYWdlcz4uICBXZSBjYW4gZG8gdHdvIHRoaW5nczoNCg0KICAgQS4gUmVuYW1lIERTS1BQJ3Mg PEtleVBhY2thZ2U+IHRvIDxLZXlDb250YWluZXI+DQoNCiAgIEIuIEluc2VydCA8S2V5UGFja2Fn ZT4gaW50byBQU0tDJ3MgPEtleUNvbnRhaW5lcj4gc3VjaCB0aGF0Og0KICAgICAgPEtleUNvbnRh aW5lcj4gIDEuLm4gIDxLZXlQYWNrYWdlPg0KICAgICAgPEtleVBhY2thZ2U+ICAgIDEuLjEgIDxE ZXZpY2U+LCA8S2V5Pg0KDQozLiBEU0tQUCBtZW50aW9ucyBwb2xpY3kgaW4gdGhlIGNvbnRleHQg b2YgYSBrZXkgaXNzdWVyJ3MgcG9saWN5IGluIHRlcm1zIG9mIHdoYXQgcHJvdG9jb2wgdmFyaWFu dCB0aGV5IHdvdWxkIGNob29zZSwgd2hhdCBlbmNyeXB0aW9uIGFsZ29yaXRobXMsIGV0Yy4gIDxQ b2xpY3k+IGFzIGRlc2NyaWJlZCBpbiBQU0tDIChlLmcuLCByZWYgUzUpIGhhcyBubyBkaXJlY3Qg cmVsYXRpb25zaGlwIHRvIGFuIGVudGl0eSBpbiBEU0tQUC4gIEkgdGhpbmsgdGhlIHdvcmQgPFBv bGljeT4gaXMgdG9vIGJyb2FkIGZvciB0aGUgcHVycG9zZSBhc3NpZ25lZCBpdCBpbiBQU0tDLiAg QSBtb3JlIHNwZWNpZmljIHRlcm0sIGxpa2UgPEtleVBvbGljeT4gbWlnaHQgYmUgYmV0dGVyLiAg KEFsdGhvdWdoIHRoZSBleGFtcGxlIHNob3duIGluIFM1IGFzc29jaWF0ZXMgPFBvbGljeT4gd2l0 aCA8S2V5PiwgaXMgdGhlcmUgZXZlciBhIHBvc3NpYmlsaXR5IHRoYXQgPFBvbGljeT4gd291bGQg Y29udGFpbiBhIGNvbmZpZ3VyYXRpb24gdGhhdCBhcHBsaWVzIHRvIGFsbCBrZXlzIGluIGEgZGV2 aWNlIChlLmcuLCA8RGV2aWNlPi0+PFBvbGljeT4pLCBhbmQgb25seSBpZiA8UG9saWN5PiBpcyBw cmVzZW50IHdpdGhpbiB0aGUgPEtleT4gZWxlbWVudCB3b3VsZCB0aGUgPEtleT4tPjxQb2xpY3k+ IG92ZXJyaWRlIDxEZXZpY2U+LT48UG9saWN5Pj8gIElmIHNvLCB0aGVuIDxLZXlQb2xpY3k+IGFz IGEgdGVybSB3b3VsZCBub3Qgd29yay4pDQoNCjQuIFM2IHJlZmVycyB0byBLZXkgRW5jcnlwdGlv biB3aGlsZSBEU0tQUCBoYXMgbWFuZGF0b3J5LXRvLWltcGxlbWVudCAiS2V5IFByb3RlY3Rpb24g TWV0aG9kcyIuICBGb3IgY2xhcml0eSwgSSByZWNvbW1lbmQgcmVmZXJyaW5nIHRvICJLZXkgRW5j cnlwdGlvbiIgYXMgIktleSBQcm90ZWN0aW9uIE1ldGhvZHMiIHRvIHByb3ZpZGUgdGhlIERTS1BQ IGltcGxlbWVudGVyIHdpdGggZWFzaWVyIGxvY2F0aW9uIHdpdGhpbiBQU0tDIG9mIHRoZSBtYW5k YXRvcnktdG8taW1wbGVtZW50IG1ldGhvZHMuDQoNCg0KRWRpdG9yaWFsOg0KLS0tLS0tLS0tLQ0K Tk9URTogU3BlbGwgY2hlY2tpbmcgYW5kIGdyYW1tYXIgY2hlY2tpbmcgc2hvdWxkIGJlIGRvbmUg YWNyb3NzIHRoZSBlbnRpcmUgZG9jdW1lbnQuICBIZXJlIGFyZSBhIGZldyBpdGVtcyBJIGZvdW5k IGR1cmluZyBteSByZXZpZXc6DQoNCiogUzEuMCAtICJzdWNoIGFzIHRob3NlIGJhc2VkIF5eb25e XiBvbmVeXi1eXnRpbWUgcGFzc3dvcmQiDQoNCiogUzEuMCAtICJzZXJ2ZXIgYW5kIF5eYXV0aGVu dGljYXRpb25eXiBzZXJ2aWNlIg0KIA0KKiBTNC4wLCBQMiAtICJleGFtcGxlIHNob3dzIFhYc3Vj aFhYIGEgc2ltcGxlIFBTS0MgZG9jdW1lbnQiDQoNCiogUzQuMCwgUDQgLSAiZWxlbWVudHMgY2Fu IGJlIHVzZWQgWFh3aGVuWFggZm9yIGJ1bGsgcHJvdmlzaW9uaW5nIg0KDQoqIFM0LjAsIFA0IC0g Iiwgc2VlIFNlY3Rpb24gOCIgKHRyeSBhbmQgYXZvaWQgZm9yd2FyZCByZWZlcmVuY2VzIGV4Y2Vw dCB0byBhcHBlbmRpY2VzKQ0KICAgICAgICAgICAgIFJlY29tbWVuZGF0aW9uOiAiJiwgc2VlIEFw cGVuZGl4IEEuMS40IGFuZCBBLjIuMSYiDQoNCiogUzQuMSwgUDEgLSAiQ29tYmluZWQgWFh0aG91 Z2ggdGhlWFggY3JpdGVyYSINCg0KKiBTNC4xLCA8RGV2aWNlQmluZGluZz4gLSAiaXMgaW50cm9k dWNlZCB0aGF0IGFsbG93cyBeXmFuIGFwcGxpY2F0aW9uXl4gdG8gYmluZCINCg0KKiBTNC4xLCA8 U3RhcnREYXRlPiAtICJ0d28gZWxlbWVudHMgaW5kaWNhdGVYWHNYWCINCg0KKiBTNC4xLCA8U3Rh cnREYXRlPiAtICJzdGFydCBhbmQgZW5kIGRhdGVeXnNeXiINCg0KKiBTNC4xLCBsYXN0IHBhcmFn cmFwaCAtICJEZXBlbmRpbmcgb24gdGhlIGRldmljZSB0eXBlXl4sXl4gY2VydGFpbiINCg0KKiBT NSwgUDMgLSAib3VyIGRlc2NyaXB0aW9uICYmYnkgZXhwYW5kaW5nIG9uJiYgdGhlIGV4YW1wbGUg c2hvd24gaW4gRmlndXJlIDMuIg0KDQoqIFM1LCA8UElOUG9saWN5PiwgJ01heExlbmd0aCcgLSAi dGhlIG1heGltdW0gbGVuZyYmdGgmJiIgb2YgYSBQSU4iDQoNCiogUzYsIFAxIC0gInByZXZpb3Vz IHNlY3Rpb25zXixeIGluZm9ybWF0aW9uIg0KDQoqIFM2LCBQMSAtICJNVVNUIGJlIHRoZSBzYW1l IGZvciBeXmFsbF5eIGVsZW1lbnRzIg0KDQoqIFM2LCBQMSAtICJLZXlzICYmYXJlIHByb3RlY3Rl ZCB1c2luZyB0aGUgZm9sbG93aW5nIG1ldGhvZHMmOiBwcmUtc2hhcmVkIGtleXMsIHBhc3NwaHJh c2UtYmFzZWQga2V5cywgYW5kIGFzeW1tZXRyaWMga2V5c15eLl5eIg0KDQoqIFM2LjEsIFAxIC0g InByb3ZpZGUgaW50ZWdyaXR5IGNoZWNrc15eLF5eIGEga2V5ZWQiDQoNCiogUzYuMSAtIEZpeCBy ZWZlcmVuY2UgdG8gSG91c2xleSBJLUQuLi50aGUgSS1EIHNob3VsZCBiZSBpbmNsdWRlZCBpbiB0 aGUgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyB3aXRoIGFuIGFwcHJvcHJpYXRlIHJlZmVyZW5jZSBo ZXJlIChlLmcuLCAiW0FFUy1LVy1JLURdIikuDQoNCiogUzYuNCwgUDEgLSAiWFgoQ0FQKVhYIFtD QVBdLiINCg0KKiBTMTMuMSAtICJJbiB0aGlzIGNhc2VeXixeXiBubyB0cmFuc3BvcnQiDQoNCg0K T3JnYW5pemF0aW9uOg0KLS0tLS0tLS0tLS0tLQ0KKiBTMS4wIC0gUGxlYXNlIHJlZmVyIHRvIERT S1BQIFMxLjEsIFMxLjIsIGFuZCBTMS4zIGZvciBWZXJzaW9uaW5nIGFuZCBYTUwgbmFtZXNwYWNl IGluZm8uICBUaGlzIHNhbWUgaW5mbyBpcyBjb3ZlcmVkIGluIFBTS0MsIGJ1dCBtdWNoIGxhdGVy LiAgSXQgd291bGQgYmUgZWFzaWVyIGZvciBLRVlQUk9WIHJlYWRlcnMgdG8gZmluZCB0aGUgaW5m byBpcyBvcmdhbml6ZWQgaW4gdGhlIHNhbWUgcGxhY2UgYWNyb3NzIGJvdGggZG9jcy4NCg0KKiBJ dCB3b3VsZCBiZSBtb3JlIGNvbnNpc3RlbnQgd2l0aCBGMSwgYW5kIG1vcmUgcmVhZGFibGUsIGlm IFM0LjQgd2VyZSBtb3ZlZCBhYm92ZSBTNC4zIChhcyBpbiBtYWtlIFM0LjQgLT4gUzQuMiwgYW5k IFM0LjMgLT4gUzQuNCkuDQo= ------_=_NextPart_001_01C9AB5C.558B8C2D-- From andrea.doherty@rsa.com Sun Mar 22 19:25:22 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666623A6B5F for ; Sun, 22 Mar 2009 19:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.319 X-Spam-Level: X-Spam-Status: No, score=-6.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 i7hA0QeemOxH for ; Sun, 22 Mar 2009 19:25:14 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 6DE5F3A6B2B for ; Sun, 22 Mar 2009 19:25:11 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n2N2PmOI023818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Mar 2009 22:25:48 -0400 (EDT) Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si03.isus.emc.com (Tablus Interceptor); Sun, 22 Mar 2009 22:25:39 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n2N2PdId022200; Sun, 22 Mar 2009 22:25:39 -0400 Received: from CORPUSMX10B.corp.emc.com ([128.221.14.95]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Mar 2009 22:25:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Mar 2009 22:25:36 -0400 Message-ID: <9ED76AB595E4944BB33D8998DE448D1102BACAE8@CORPUSMX10B.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for additional KEYPROV WG agenda item Thread-Index: AcmbdG0kQdZ9gzkBRaWaA1IllFfNxAP6RifM References: <034301c99b74$737c5710$0201a8c0@nsnintra.net> From: To: , , , , , X-OriginalArrivalTime: 23 Mar 2009 02:25:38.0958 (UTC) FILETIME=[A7F02AE0:01C9AB5E] X-EMM-EM: Active Cc: keyprov@ietf.org Subject: [KEYPROV] Request for additional KEYPROV WG agenda item X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 02:25:22 -0000 Hannes, =20 We would like to request an additional agenda item to discuss topics = general to KEYPROV work-in-progress. In particular: *Comments regarding terminology alignment issues between PSKC and DSKPP = that were received on the mailing list, esp. those from Pasi and I. =20 Please let us know if the terminology alignment topic can be added to = the agenda. If so, Philip Hoyer and I will provide 2 or 3 slides, which = I will present. =20 BTW - Another general topic is algorithm profiles work, e.g., = draft-hoyer-keyprov-pskc-algorithm-profiles-00.txt. Would be good if = mentioned in the meeting, but not sure it belongs in its own = presentation. =20 Thanks, Andrea =20 From Hannes.Tschofenig@gmx.net Mon Mar 23 07:33:00 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B1F23A67DD for ; Mon, 23 Mar 2009 07:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599] 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 i1i6QDr4u+xs for ; Mon, 23 Mar 2009 07:32:59 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DEE6F28C10E for ; Mon, 23 Mar 2009 07:32:44 -0700 (PDT) Received: (qmail invoked by alias); 23 Mar 2009 14:33:34 -0000 Received: from dhcp-43b3.meeting.ietf.org (EHLO 4FIL42860) [130.129.67.179] by mail.gmx.net (mp071) with SMTP; 23 Mar 2009 15:33:34 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/EcicwNTfEbsvnBMqSwvdrdeGmCafqdMrFTl/ZLp ilu77NVm91uDpZ From: "Hannes Tschofenig" To: "'KEYPROV'" Date: Mon, 23 Mar 2009 07:34:45 -0700 Message-ID: <007b01c9abc4$84f9e880$f7148182@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmqeCwiBTbkqSCdR1KGZF0ZrSNq2ABS2YCQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: [KEYPROV] FW: Audio Streams for IETF 74 in San Francisco X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 14:33:00 -0000 FYI Jabber for the meeting: keyprov@jabber.ietf.org >-----Original Message----- >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On >Behalf Of Morgan Sackett >Sent: 21 March, 2009 15:55 >To: ietf@ietf.org >Subject: Audio Streams for IETF 74 in San Francisco > >There will be MP3 audio streams of the meetings happening in >the breakout rooms. Specifically these are > >Continental 1&2 >Continental 3 >Continental 4 >Continental 5 >Continental 6 >Imperial A >Imperial B >Franciscan A > >Please refer to the online agenda at >http://tools.ietf.org/agenda/74/ to find a link to the stream >for each session. > >If there are concerns about the audio streams, there are a few >ways to get our attention. Via email either >audio@meeting.ietf.org, or noc@meeting.ietf.org . Via XMPP at >noc@jabber.ietf.org. > >Morgan Sackett >VP of Engineering > >VeriLAN Event Services, Inc. >215 SE Morrison Street >Portland, OR 97214 > >Tel: 503 907-1415 >Fax: 503 224-8833 > >msackett@verilan.com >www.verilan.com > > >This e-mail contains proprietary information and may be confidential. >If you are not the intended recipient of this e-mail, you are >hereby notified that any dissemination, distribution or >copying of this message is strictly prohibited. If you >received this message in error, please delete it immediately. > > > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf > From andrea.doherty@rsa.com Mon Mar 23 20:43:04 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441D73A688E for ; Mon, 23 Mar 2009 20:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 BwYzeLEYrDgO for ; Mon, 23 Mar 2009 20:43:03 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 6866B3A68FD for ; Mon, 23 Mar 2009 20:42:57 -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.2.5/Switch-3.1.7) with ESMTP id n2O3hkJD012357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Mar 2009 23:43:46 -0400 (EDT) Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.15]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor) for ; Mon, 23 Mar 2009 23:43:37 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n2O3hb2N024339 for ; Mon, 23 Mar 2009 23:43:37 -0400 Received: from CORPUSMX10B.corp.emc.com ([128.221.14.95]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 23:43:36 -0400 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: Mon, 23 Mar 2009 23:43:29 -0400 Message-ID: <9ED76AB595E4944BB33D8998DE448D1104D77541@CORPUSMX10B.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DSKPP and Thread-Index: AcmsMrH8/RPW4y6tQ1S6AN1GGyG/Yw== From: To: X-OriginalArrivalTime: 24 Mar 2009 03:43:37.0097 (UTC) FILETIME=[B6BD4790:01C9AC32] X-EMM-EM: Active Subject: [KEYPROV] DSKPP and X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 03:43:04 -0000 , which relies on are very specific to OTP tokens. These entities were included in the original RFC4758 (CT-KIP) as a way of passing token information in the trigger message. However, since then the protocol extension was added, which can be used for the same purpose, but is more generic. Eliminating redundant entities such as and will make the document more readable and easier to implement. As such, I plan to remove these entities in the next update of DSKPP (-08) unless I hear comments to the contrary. I'll produce a new update in April. Andrea From anders.rundgren@telia.com Tue Mar 24 13:59:54 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648183A6D2F for ; Tue, 24 Mar 2009 13:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.644 X-Spam-Level: X-Spam-Status: No, score=-0.644 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 nHaHrWb1nNyH for ; Tue, 24 Mar 2009 13:59:53 -0700 (PDT) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by core3.amsl.com (Postfix) with ESMTP id 89B3C3A6989 for ; Tue, 24 Mar 2009 13:59:53 -0700 (PDT) Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C5035AB303 for keyprov@ietf.org; Tue, 24 Mar 2009 22:00:44 +0100 Message-ID: <5CCF33D18F304FAC87DAC1F428700244@AndersPC> From: "Anders Rundgren" To: "KEYPROV" Date: Tue, 24 Mar 2009 22:01:08 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0129_01C9ACCC.094CE530" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.20661 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Subject: [KEYPROV] IETF KEYPROV bar discussion topic X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:59:54 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0129_01C9ACCC.094CE530 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A major problem with stuff like KEYPROV and KeyGen2 as well as older = schemes like , generateCRMFRequest() and CertEnroll is the = absence of a suitable container and compatible middleware for = cryptographic keys. It is true that governments, banks and a fraction of private businesses = can afford the hassle and cost associated with regular smart cards but = the fact is that they almost without exception use physical token = distribution making provisioning protocols of pretty marginal interest. I guess this is already a dead duck, but I don't see why it is = impossible to set aside 10M of flash in a (reprogrammed) but HW-wise = standard USB memory stick and use that for key storage and execution. Anders Rundgren ------=_NextPart_000_0129_01C9ACCC.094CE530 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A major problem with stuff like KEYPROV = and KeyGen2 as well as older schemes like <keygen>,=20 generateCRMFRequest() and CertEnroll is the absence of a suitable = container and=20 compatible middleware for cryptographic keys.
 
It is true that governments, banks and = a fraction=20 of private businesses can afford the hassle and cost=20 associated with regular smart cards but the fact is that they = almost=20 without exception use physical token distribution making provisioning = protocols=20 of pretty marginal interest.
 
I guess this is already a dead duck, = but I don't=20 see why it is impossible to set aside 10M of flash in a (reprogrammed) = but=20 HW-wise standard USB memory stick and use that for key storage and=20 execution.
 
Anders Rundgren
 
 
------=_NextPart_000_0129_01C9ACCC.094CE530-- From Pasi.Eronen@nokia.com Tue Mar 24 18:46:13 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95B53A6945 for ; Tue, 24 Mar 2009 18:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 A5i9k5S3RDg3 for ; Tue, 24 Mar 2009 18:46:13 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id A1A553A68B9 for ; Tue, 24 Mar 2009 18:46:12 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2P1kl70010409 for ; Wed, 25 Mar 2009 03:46:59 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 03:45:58 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 03:45:53 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 25 Mar 2009 02:45:53 +0100 From: To: Date: Wed, 25 Mar 2009 02:45:52 +0100 Thread-Topic: My notes from today Thread-Index: Acms6236ZbPN91oQRTiLhHxN0dI8Gw== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F20B4A3F@NOK-EUMSG-01.mgdnok.nokia.com> 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-OriginalArrivalTime: 25 Mar 2009 01:45:53.0654 (UTC) FILETIME=[6F032960:01C9ACEB] X-Nokia-AV: Clean Subject: [KEYPROV] My notes from today X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 01:46:13 -0000 Writing these down before the social event...=20 Key: A logical component that performs symmetric key operations using a Key Value, Key Attributes, and other state.=20 Key Value: The secret value used by a Key. (DSKPP and PSKC treat this as a single key, although there could be some internal structure.) Key Attributes: Set of information that influence how the Key Value will be used, and how the Key can be used. Example: The length of OTP value (for OTP algorithms that support variable length OTPs), date after which the Key should not be used, how access to Key functionality should be controlled (e.g. local PIN code). Key Type: Determines how a Key works: for example, the allowed lengths of the Key Value, the cryptographic operations that can be performed (e.g. OTP computation or challenge-response) and their inputs, outputs, and algorithms; and what Key Attributes can be used. Example: some examples of one-time password Key Types are HOTP [RFC4226], S/Key [RFC1760], and SecurID-AES. In DSKPP and PSKC,=20 Key Types are identified by URIs. Cryptographic Module: A logical component that contains one or more Keys. Can be implemented in hardware or software. Device: The physical device implementing the Cryptographic Module. Example: For hardware Cryptographic Modules, a single Device usually contains only one Cryptographic Module. For software Cryptographic Modules, the Device is the host device (laptop, server, mobile phone, etc.), and can contain multiple=20 Cryptographic Modules. Key Package: A data structure for moving a single Key from one Cryptographic Module to another. Contains data about the Key (e.g. Key Value and Attributes), Cryptographic Module (e.g. source or intended destination Key), Device, Issuer (an organization or party that manages some Keys -- and possibly Cryptographic Modules and/or Devices -- or has some kind of authority over them), and User (user, account, role, or other entity that uses the services provided by Key, or is otherwise associated with it). =20 Key Container: A data structure or file containing one or more Key Packages. These were not discussed, but should be very straightforward: DSKPP Client: The logical entity implementing the client part of DSKPP protocol; communicates with an Cryptographic Module to provision Keys to the Cryptographic Module. In case of Hardware Cryptographic Modules, the DSKPP Client might run on a PC to which the Hardware Cryptographic Module is connected. In case of Software Cryptographic Modules, the DSKPP Client could be part of the same software package as the Cryptographic Module itself, or separate. (The interface between the Cryptographic Module and the DSKPP Client is not specified in this document.) DSKPP Server: The logical entity that communicates with the DSKPP client; usually communicates with a server-side Cryptographic Module so that a corresponding Key (with the same Key Value) exists also on the server side. The interface between the DSKPP Server and the server-side Cryptographic Module is beyond the scope of this document. -------------- ...info about Key ...info about Cryptographic Module ...info about Device ...info about Issuer ...info about User .... .... -------- Best regards, Pasi From philip.hoyer@actividentity.com Wed Mar 25 02:31:19 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6AB3A67FB for ; Wed, 25 Mar 2009 02:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 R7xLSwJO6u5d for ; Wed, 25 Mar 2009 02:31:18 -0700 (PDT) Received: from frhub1.activcard.fr (frhub1.activcard.fr [91.151.120.133]) by core3.amsl.com (Postfix) with ESMTP id 20C813A679F for ; Wed, 25 Mar 2009 02:31:18 -0700 (PDT) Received: from sur-corp-ex-02.corp.ad.activcard.com (sur-corp-ex-02.corp.ad.activcard.com [192.168.33.40]) by frhub1.activcard.fr (Postfix) with ESMTP id 05E8A183989; Wed, 25 Mar 2009 10:32:09 +0100 (CET) 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, 25 Mar 2009 10:35:31 +0100 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB73D9@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F20B4A3F@NOK-EUMSG-01.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] My notes from today Thread-Index: Acms6236ZbPN91oQRTiLhHxN0dI8GwAP7zOg References: <808FD6E27AD4884E94820BC333B2DB7727F20B4A3F@NOK-EUMSG-01.mgdnok.nokia.com> From: "Philip Hoyer" To: , Subject: Re: [KEYPROV] My notes from today X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 09:31:19 -0000 Pasi, I think we are getting to some consensus. I was wondering if Key, KeyAttributes and KeyType need a bit more analysis. I believe that we should explicitly model KeyPolicy e.g. the Policy governing the use of the key, hence this would be: - Usage (encryption, decription, OTP, etc) - permitted dates the key can be used - permitted number of transactions - PINPoliicy - etc Then we have the key and its algorithm There is the concept of static parameters for a specific algorithm for example - IV=20 - OTP length - format produced And then for some algorithm types we have the concept of dynamic values/meta_data, tied to a key for example: - OTP event counter - time drift Now I am not sure if we need to split them out but currently in PSKC we have modeled them separately - dynamic value are under Key.Data (e.g. Key.Data.Counter) - static values are under Key.Usage (e.g. Key.Usage.ResponseFormat) The other point I wanted to make is that the User binding currently can be on a device level AND on a Key level and the Users could be different so maybe we should leave the user under the respective sub elements: ...info about Key Algorithm (under here we could put the current Key.Usage and rename them as algorithm.parameters) Data (dynamic data) Policy ...info about User ...info about Issuer ...info about Cryptographic Module ...info about Device SerialNo Manufacturer ...info about User etc .... .... Philip -----Original Message----- From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Wednesday, March 25, 2009 1:46 AM To: keyprov@ietf.org Subject: [KEYPROV] My notes from today Writing these down before the social event...=20 Key: A logical component that performs symmetric key operations using a Key Value, Key Attributes, and other state.=20 Key Value: The secret value used by a Key. (DSKPP and PSKC treat this as a single key, although there could be some internal structure.) Key Attributes: Set of information that influence how the Key Value will be used, and how the Key can be used. Example: The length of OTP value (for OTP algorithms that support variable length OTPs), date after which the Key should not be used, how access to Key functionality should be controlled (e.g. local PIN code). Key Type: Determines how a Key works: for example, the allowed lengths of the Key Value, the cryptographic operations that can be performed (e.g. OTP computation or challenge-response) and their inputs, outputs, and algorithms; and what Key Attributes can be used. Example: some examples of one-time password Key Types are HOTP [RFC4226], S/Key [RFC1760], and SecurID-AES. In DSKPP and PSKC,=20 Key Types are identified by URIs. Cryptographic Module: A logical component that contains one or more Keys. Can be implemented in hardware or software. Device: The physical device implementing the Cryptographic Module. Example: For hardware Cryptographic Modules, a single Device usually contains only one Cryptographic Module. For software Cryptographic Modules, the Device is the host device (laptop, server, mobile phone, etc.), and can contain multiple=20 Cryptographic Modules. Key Package: A data structure for moving a single Key from one Cryptographic Module to another. Contains data about the Key (e.g. Key Value and Attributes), Cryptographic Module (e.g. source or intended destination Key), Device, Issuer (an organization or party that manages some Keys -- and possibly Cryptographic Modules and/or Devices -- or has some kind of authority over them), and User (user, account, role, or other entity that uses the services provided by Key, or is otherwise associated with it). =20 Key Container: A data structure or file containing one or more Key Packages. These were not discussed, but should be very straightforward: DSKPP Client: The logical entity implementing the client part of DSKPP protocol; communicates with an Cryptographic Module to provision Keys to the Cryptographic Module. In case of Hardware Cryptographic Modules, the DSKPP Client might run on a PC to which the Hardware Cryptographic Module is connected. In case of Software Cryptographic Modules, the DSKPP Client could be part of the same software package as the Cryptographic Module itself, or separate. (The interface between the Cryptographic Module and the DSKPP Client is not specified in this document.) DSKPP Server: The logical entity that communicates with the DSKPP client; usually communicates with a server-side Cryptographic Module so that a corresponding Key (with the same Key Value) exists also on the server side. The interface between the DSKPP Server and the server-side Cryptographic Module is beyond the scope of this document. -------------- ...info about Key ...info about Cryptographic Module ...info about Device ...info about Issuer ...info about User .... .... -------- Best regards, Pasi _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov From mpei@verisign.com Wed Mar 25 11:14:07 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121183A6AE4 for ; Wed, 25 Mar 2009 11:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 mOrmD44x7dID for ; Wed, 25 Mar 2009 11:14:05 -0700 (PDT) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id E44953A67B4 for ; Wed, 25 Mar 2009 11:14:05 -0700 (PDT) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n2PHnQWo022410; Wed, 25 Mar 2009 10:49:26 -0700 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 11:14:56 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 25 Mar 2009 11:14:55 -0700 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C90126DAD3@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB73D9@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] My notes from today Thread-Index: Acms6236ZbPN91oQRTiLhHxN0dI8GwAP7zOgABJdnnA= References: <808FD6E27AD4884E94820BC333B2DB7727F20B4A3F@NOK-EUMSG-01.mgdnok.nokia.com> <5BFE9E473DBFC24CA87F18F29B3F0AC403EB73D9@sur-corp-ex-02.corp.ad.activcard.com> From: "Pei, Mingliang" To: "Philip Hoyer" , , X-OriginalArrivalTime: 25 Mar 2009 18:14:56.0631 (UTC) FILETIME=[9A2ED870:01C9AD75] Subject: Re: [KEYPROV] My notes from today X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:14:07 -0000 I just add one point that we also discussed and agreed: A key may have multiple "secrets" - for example, a PIN associated with a key in addition to KeyValue. Keypackage means to contain one single key and it can still conceptually cover the case. A keypackage should be able to contain all such related information for a key. It is our data structure choice today in PSKC that we reuse to carry a PIN. But that was a structure choice, not the logic concept. The structure inside Keypackage should allow a key value and PIN. The PIN is conceptually an attribute of the key. The data structure could continue to use or a variant within KeyPackage. KeyPackage can mostly replace the current in PSKC but we need some more structure reorganization for proper fit to handle all three kinds of attributes (device, cryptographic module, and key). - Ming -----Original Message----- From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Philip Hoyer Sent: Wednesday, March 25, 2009 2:36 AM To: Pasi.Eronen@nokia.com; keyprov@ietf.org Subject: Re: [KEYPROV] My notes from today Pasi, I think we are getting to some consensus. I was wondering if Key, KeyAttributes and KeyType need a bit more analysis. I believe that we should explicitly model KeyPolicy e.g. the Policy governing the use of the key, hence this would be: - Usage (encryption, decription, OTP, etc) - permitted dates the key can be used - permitted number of transactions - PINPoliicy - etc Then we have the key and its algorithm There is the concept of static parameters for a specific algorithm for example - IV - OTP length - format produced And then for some algorithm types we have the concept of dynamic values/meta_data, tied to a key for example: - OTP event counter - time drift Now I am not sure if we need to split them out but currently in PSKC we have modeled them separately - dynamic value are under Key.Data (e.g. Key.Data.Counter) - static values are under Key.Usage (e.g. Key.Usage.ResponseFormat) The other point I wanted to make is that the User binding currently can be on a device level AND on a Key level and the Users could be different so maybe we should leave the user under the respective sub elements: ...info about Key Algorithm (under here we could put the current Key.Usage and rename them as algorithm.parameters) Data (dynamic data) Policy ...info about User ...info about Issuer ...info about Cryptographic Module ...info about Device SerialNo Manufacturer ...info about User etc .... .... Philip -----Original Message----- From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Wednesday, March 25, 2009 1:46 AM To: keyprov@ietf.org Subject: [KEYPROV] My notes from today Writing these down before the social event...=20 Key: A logical component that performs symmetric key operations using a Key Value, Key Attributes, and other state.=20 Key Value: The secret value used by a Key. (DSKPP and PSKC treat this as a single key, although there could be some internal structure.) Key Attributes: Set of information that influence how the Key Value will be used, and how the Key can be used. Example: The length of OTP value (for OTP algorithms that support variable length OTPs), date after which the Key should not be used, how access to Key functionality should be controlled (e.g. local PIN code). Key Type: Determines how a Key works: for example, the allowed lengths of the Key Value, the cryptographic operations that can be performed (e.g. OTP computation or challenge-response) and their inputs, outputs, and algorithms; and what Key Attributes can be used. Example: some examples of one-time password Key Types are HOTP [RFC4226], S/Key [RFC1760], and SecurID-AES. In DSKPP and PSKC,=20 Key Types are identified by URIs. Cryptographic Module: A logical component that contains one or more Keys. Can be implemented in hardware or software. Device: The physical device implementing the Cryptographic Module. Example: For hardware Cryptographic Modules, a single Device usually contains only one Cryptographic Module. For software Cryptographic Modules, the Device is the host device (laptop, server, mobile phone, etc.), and can contain multiple=20 Cryptographic Modules. Key Package: A data structure for moving a single Key from one Cryptographic Module to another. Contains data about the Key (e.g. Key Value and Attributes), Cryptographic Module (e.g. source or intended destination Key), Device, Issuer (an organization or party that manages some Keys -- and possibly Cryptographic Modules and/or Devices -- or has some kind of authority over them), and User (user, account, role, or other entity that uses the services provided by Key, or is otherwise associated with it). =20 Key Container: A data structure or file containing one or more Key Packages. These were not discussed, but should be very straightforward: DSKPP Client: The logical entity implementing the client part of DSKPP protocol; communicates with an Cryptographic Module to provision Keys to the Cryptographic Module. In case of Hardware Cryptographic Modules, the DSKPP Client might run on a PC to which the Hardware Cryptographic Module is connected. In case of Software Cryptographic Modules, the DSKPP Client could be part of the same software package as the Cryptographic Module itself, or separate. (The interface between the Cryptographic Module and the DSKPP Client is not specified in this document.) DSKPP Server: The logical entity that communicates with the DSKPP client; usually communicates with a server-side Cryptographic Module so that a corresponding Key (with the same Key Value) exists also on the server side. The interface between the DSKPP Server and the server-side Cryptographic Module is beyond the scope of this document. -------------- ...info about Key ...info about Cryptographic Module ...info about Device ...info about Issuer ...info about User .... .... -------- Best regards, Pasi _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov From philip.hoyer@actividentity.com Wed Mar 25 11:16:52 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CF373A6BD9 for ; Wed, 25 Mar 2009 11:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 JKlKejO5tjww for ; Wed, 25 Mar 2009 11:16:51 -0700 (PDT) Received: from frhub1.activcard.fr (frhub1.activcard.fr [91.151.120.133]) by core3.amsl.com (Postfix) with ESMTP id 1EAFC3A6D5D for ; Wed, 25 Mar 2009 11:16:51 -0700 (PDT) Received: from sur-corp-ex-02.corp.ad.activcard.com (sur-corp-ex-02.corp.ad.activcard.com [192.168.33.40]) by frhub1.activcard.fr (Postfix) with ESMTP id B5F7218396F; Wed, 25 Mar 2009 19:17:42 +0100 (CET) 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, 25 Mar 2009 19:21:05 +0100 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB73E1@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <3E5A2F1AD44F5E49A74F79AB47C0C0C90126DAD3@mou1wnexmb10.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] My notes from today Thread-Index: Acms6236ZbPN91oQRTiLhHxN0dI8GwAP7zOgABJdnnAAAGbIEA== References: <808FD6E27AD4884E94820BC333B2DB7727F20B4A3F@NOK-EUMSG-01.mgdnok.nokia.com> <5BFE9E473DBFC24CA87F18F29B3F0AC403EB73D9@sur-corp-ex-02.corp.ad.activcard.com> <3E5A2F1AD44F5E49A74F79AB47C0C0C90126DAD3@mou1wnexmb10.vcorp.ad.vrsn.com> From: "Philip Hoyer" To: "Pei, Mingliang" , , Subject: Re: [KEYPROV] My notes from today X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:16:52 -0000 Ming, PIN is interesting again since normally it spans multiple keys and is shared hence the reference mechanism used today.=20 In this sense it might be better to wrap PIN as a separate KeyPackage and refer to it from within PINPolicy Philip -----Original Message----- From: Pei, Mingliang [mailto:mpei@verisign.com]=20 Sent: Wednesday, March 25, 2009 6:15 PM To: Philip Hoyer; Pasi.Eronen@nokia.com; keyprov@ietf.org Subject: RE: [KEYPROV] My notes from today I just add one point that we also discussed and agreed: A key may have multiple "secrets" - for example, a PIN associated with a key in addition to KeyValue. Keypackage means to contain one single key and it can still conceptually cover the case. A keypackage should be able to contain all such related information for a key. It is our data structure choice today in PSKC that we reuse to carry a PIN. But that was a structure choice, not the logic concept. The structure inside Keypackage should allow a key value and PIN. The PIN is conceptually an attribute of the key. The data structure could continue to use or a variant within KeyPackage. KeyPackage can mostly replace the current in PSKC but we need some more structure reorganization for proper fit to handle all three kinds of attributes (device, cryptographic module, and key). - Ming -----Original Message----- From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Philip Hoyer Sent: Wednesday, March 25, 2009 2:36 AM To: Pasi.Eronen@nokia.com; keyprov@ietf.org Subject: Re: [KEYPROV] My notes from today Pasi, I think we are getting to some consensus. I was wondering if Key, KeyAttributes and KeyType need a bit more analysis. I believe that we should explicitly model KeyPolicy e.g. the Policy governing the use of the key, hence this would be: - Usage (encryption, decription, OTP, etc) - permitted dates the key can be used - permitted number of transactions - PINPoliicy - etc Then we have the key and its algorithm There is the concept of static parameters for a specific algorithm for example - IV - OTP length - format produced And then for some algorithm types we have the concept of dynamic values/meta_data, tied to a key for example: - OTP event counter - time drift Now I am not sure if we need to split them out but currently in PSKC we have modeled them separately - dynamic value are under Key.Data (e.g. Key.Data.Counter) - static values are under Key.Usage (e.g. Key.Usage.ResponseFormat) The other point I wanted to make is that the User binding currently can be on a device level AND on a Key level and the Users could be different so maybe we should leave the user under the respective sub elements: ...info about Key Algorithm (under here we could put the current Key.Usage and rename them as algorithm.parameters) Data (dynamic data) Policy ...info about User ...info about Issuer ...info about Cryptographic Module ...info about Device SerialNo Manufacturer ...info about User etc .... .... Philip -----Original Message----- From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Wednesday, March 25, 2009 1:46 AM To: keyprov@ietf.org Subject: [KEYPROV] My notes from today Writing these down before the social event...=20 Key: A logical component that performs symmetric key operations using a Key Value, Key Attributes, and other state.=20 Key Value: The secret value used by a Key. (DSKPP and PSKC treat this as a single key, although there could be some internal structure.) Key Attributes: Set of information that influence how the Key Value will be used, and how the Key can be used. Example: The length of OTP value (for OTP algorithms that support variable length OTPs), date after which the Key should not be used, how access to Key functionality should be controlled (e.g. local PIN code). Key Type: Determines how a Key works: for example, the allowed lengths of the Key Value, the cryptographic operations that can be performed (e.g. OTP computation or challenge-response) and their inputs, outputs, and algorithms; and what Key Attributes can be used. Example: some examples of one-time password Key Types are HOTP [RFC4226], S/Key [RFC1760], and SecurID-AES. In DSKPP and PSKC,=20 Key Types are identified by URIs. Cryptographic Module: A logical component that contains one or more Keys. Can be implemented in hardware or software. Device: The physical device implementing the Cryptographic Module. Example: For hardware Cryptographic Modules, a single Device usually contains only one Cryptographic Module. For software Cryptographic Modules, the Device is the host device (laptop, server, mobile phone, etc.), and can contain multiple=20 Cryptographic Modules. Key Package: A data structure for moving a single Key from one Cryptographic Module to another. Contains data about the Key (e.g. Key Value and Attributes), Cryptographic Module (e.g. source or intended destination Key), Device, Issuer (an organization or party that manages some Keys -- and possibly Cryptographic Modules and/or Devices -- or has some kind of authority over them), and User (user, account, role, or other entity that uses the services provided by Key, or is otherwise associated with it). =20 Key Container: A data structure or file containing one or more Key Packages. These were not discussed, but should be very straightforward: DSKPP Client: The logical entity implementing the client part of DSKPP protocol; communicates with an Cryptographic Module to provision Keys to the Cryptographic Module. In case of Hardware Cryptographic Modules, the DSKPP Client might run on a PC to which the Hardware Cryptographic Module is connected. In case of Software Cryptographic Modules, the DSKPP Client could be part of the same software package as the Cryptographic Module itself, or separate. (The interface between the Cryptographic Module and the DSKPP Client is not specified in this document.) DSKPP Server: The logical entity that communicates with the DSKPP client; usually communicates with a server-side Cryptographic Module so that a corresponding Key (with the same Key Value) exists also on the server side. The interface between the DSKPP Server and the server-side Cryptographic Module is beyond the scope of this document. -------------- ...info about Key ...info about Cryptographic Module ...info about Device ...info about Issuer ...info about User .... .... -------- Best regards, Pasi _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov From mpei@verisign.com Wed Mar 25 11:23:40 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030F63A69B5 for ; Wed, 25 Mar 2009 11:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 2YjZtsdNoFdI for ; Wed, 25 Mar 2009 11:23:38 -0700 (PDT) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id CFADC3A67DF for ; Wed, 25 Mar 2009 11:23:38 -0700 (PDT) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n2PIORXk028279; Wed, 25 Mar 2009 11:24:27 -0700 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 11:24:27 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 25 Mar 2009 11:24:26 -0700 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C90126DAD5@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB73E1@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] My notes from today Thread-Index: Acms6236ZbPN91oQRTiLhHxN0dI8GwAP7zOgABJdnnAAAGbIEAAAAD1Q References: <808FD6E27AD4884E94820BC333B2DB7727F20B4A3F@NOK-EUMSG-01.mgdnok.nokia.com> <5BFE9E473DBFC24CA87F18F29B3F0AC403EB73D9@sur-corp-ex-02.corp.ad.activcard.com> <3E5A2F1AD44F5E49A74F79AB47C0C0C90126DAD3@mou1wnexmb10.vcorp.ad.vrsn.com> <5BFE9E473DBFC24CA87F18F29B3F0AC403EB73E1@sur-corp-ex-02.corp.ad.activcard.com> From: "Pei, Mingliang" To: "Philip Hoyer" , , X-OriginalArrivalTime: 25 Mar 2009 18:24:27.0129 (UTC) FILETIME=[EE39EE90:01C9AD76] Subject: Re: [KEYPROV] My notes from today X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:23:40 -0000 It is fine to do this way - the similar thought we used Key for reference. The main change that we need from the discussion is to move Device attributes into Key, and promoto Key up to KeyPackage. It could be simply this change, or further revisit on grouping key usage, policy and data etc within a key package in your email. I incline to do the simple change, which aligns our concept model with DSKPP. - Ming=20 -----Original Message----- From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Wednesday, March 25, 2009 11:21 AM To: Pei, Mingliang; Pasi.Eronen@nokia.com; keyprov@ietf.org Subject: RE: [KEYPROV] My notes from today Ming, PIN is interesting again since normally it spans multiple keys and is shared hence the reference mechanism used today.=20 In this sense it might be better to wrap PIN as a separate KeyPackage and refer to it from within PINPolicy Philip -----Original Message----- From: Pei, Mingliang [mailto:mpei@verisign.com] Sent: Wednesday, March 25, 2009 6:15 PM To: Philip Hoyer; Pasi.Eronen@nokia.com; keyprov@ietf.org Subject: RE: [KEYPROV] My notes from today I just add one point that we also discussed and agreed: A key may have multiple "secrets" - for example, a PIN associated with a key in addition to KeyValue. Keypackage means to contain one single key and it can still conceptually cover the case. A keypackage should be able to contain all such related information for a key. It is our data structure choice today in PSKC that we reuse to carry a PIN. But that was a structure choice, not the logic concept. The structure inside Keypackage should allow a key value and PIN. The PIN is conceptually an attribute of the key. The data structure could continue to use or a variant within KeyPackage. KeyPackage can mostly replace the current in PSKC but we need some more structure reorganization for proper fit to handle all three kinds of attributes (device, cryptographic module, and key). - Ming -----Original Message----- From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Philip Hoyer Sent: Wednesday, March 25, 2009 2:36 AM To: Pasi.Eronen@nokia.com; keyprov@ietf.org Subject: Re: [KEYPROV] My notes from today Pasi, I think we are getting to some consensus. I was wondering if Key, KeyAttributes and KeyType need a bit more analysis. I believe that we should explicitly model KeyPolicy e.g. the Policy governing the use of the key, hence this would be: - Usage (encryption, decription, OTP, etc) - permitted dates the key can be used - permitted number of transactions - PINPoliicy - etc Then we have the key and its algorithm There is the concept of static parameters for a specific algorithm for example - IV - OTP length - format produced And then for some algorithm types we have the concept of dynamic values/meta_data, tied to a key for example: - OTP event counter - time drift Now I am not sure if we need to split them out but currently in PSKC we have modeled them separately - dynamic value are under Key.Data (e.g. Key.Data.Counter) - static values are under Key.Usage (e.g. Key.Usage.ResponseFormat) The other point I wanted to make is that the User binding currently can be on a device level AND on a Key level and the Users could be different so maybe we should leave the user under the respective sub elements: ...info about Key Algorithm (under here we could put the current Key.Usage and rename them as algorithm.parameters) Data (dynamic data) Policy ...info about User ...info about Issuer ...info about Cryptographic Module ...info about Device SerialNo Manufacturer ...info about User etc .... .... Philip -----Original Message----- From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Wednesday, March 25, 2009 1:46 AM To: keyprov@ietf.org Subject: [KEYPROV] My notes from today Writing these down before the social event...=20 Key: A logical component that performs symmetric key operations using a Key Value, Key Attributes, and other state.=20 Key Value: The secret value used by a Key. (DSKPP and PSKC treat this as a single key, although there could be some internal structure.) Key Attributes: Set of information that influence how the Key Value will be used, and how the Key can be used. Example: The length of OTP value (for OTP algorithms that support variable length OTPs), date after which the Key should not be used, how access to Key functionality should be controlled (e.g. local PIN code). Key Type: Determines how a Key works: for example, the allowed lengths of the Key Value, the cryptographic operations that can be performed (e.g. OTP computation or challenge-response) and their inputs, outputs, and algorithms; and what Key Attributes can be used. Example: some examples of one-time password Key Types are HOTP [RFC4226], S/Key [RFC1760], and SecurID-AES. In DSKPP and PSKC,=20 Key Types are identified by URIs. Cryptographic Module: A logical component that contains one or more Keys. Can be implemented in hardware or software. Device: The physical device implementing the Cryptographic Module. Example: For hardware Cryptographic Modules, a single Device usually contains only one Cryptographic Module. For software Cryptographic Modules, the Device is the host device (laptop, server, mobile phone, etc.), and can contain multiple=20 Cryptographic Modules. Key Package: A data structure for moving a single Key from one Cryptographic Module to another. Contains data about the Key (e.g. Key Value and Attributes), Cryptographic Module (e.g. source or intended destination Key), Device, Issuer (an organization or party that manages some Keys -- and possibly Cryptographic Modules and/or Devices -- or has some kind of authority over them), and User (user, account, role, or other entity that uses the services provided by Key, or is otherwise associated with it). =20 Key Container: A data structure or file containing one or more Key Packages. These were not discussed, but should be very straightforward: DSKPP Client: The logical entity implementing the client part of DSKPP protocol; communicates with an Cryptographic Module to provision Keys to the Cryptographic Module. In case of Hardware Cryptographic Modules, the DSKPP Client might run on a PC to which the Hardware Cryptographic Module is connected. In case of Software Cryptographic Modules, the DSKPP Client could be part of the same software package as the Cryptographic Module itself, or separate. (The interface between the Cryptographic Module and the DSKPP Client is not specified in this document.) DSKPP Server: The logical entity that communicates with the DSKPP client; usually communicates with a server-side Cryptographic Module so that a corresponding Key (with the same Key Value) exists also on the server side. The interface between the DSKPP Server and the server-side Cryptographic Module is beyond the scope of this document. -------------- ...info about Key ...info about Cryptographic Module ...info about Device ...info about Issuer ...info about User .... .... -------- Best regards, Pasi _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov From SBajaj@verisign.com Wed Mar 25 14:41:43 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9853A6DB4 for ; Wed, 25 Mar 2009 14:41:43 -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=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 l-z2eFY5GOw5 for ; Wed, 25 Mar 2009 14:41:42 -0700 (PDT) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id CA89E3A6DA7 for ; Wed, 25 Mar 2009 14:41:42 -0700 (PDT) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n2PLH2bq012973; Wed, 25 Mar 2009 14:17:02 -0700 Received: from MOU1WNEXMB03.vcorp.ad.vrsn.com ([10.25.13.156]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 14:42:32 -0700 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, 25 Mar 2009 14:42:27 -0700 Message-ID: In-Reply-To: <3E5A2F1AD44F5E49A74F79AB47C0C0C90126DAD5@mou1wnexmb10.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] My notes from today Thread-Index: Acms6236ZbPN91oQRTiLhHxN0dI8GwAP7zOgABJdnnAAAGbIEAAAAD1QAAcFJ9A= References: <808FD6E27AD4884E94820BC333B2DB7727F20B4A3F@NOK-EUMSG-01.mgdnok.nokia.com><5BFE9E473DBFC24CA87F18F29B3F0AC403EB73D9@sur-corp-ex-02.corp.ad.activcard.com><3E5A2F1AD44F5E49A74F79AB47C0C0C90126DAD3@mou1wnexmb10.vcorp.ad.vrsn.com><5BFE9E473DBFC24CA87F18F29B3F0AC403EB73E1@sur-corp-ex-02.corp.ad.activcard.com> <3E5A2F1AD44F5E49A74F79AB47C0C0C90126DAD5@mou1wnexmb10.vcorp.ad.vrsn.com> From: "Bajaj, Siddharth" To: "Pei, Mingliang" , "Philip Hoyer" , , X-OriginalArrivalTime: 25 Mar 2009 21:42:32.0898 (UTC) FILETIME=[9AB25A20:01C9AD92] Subject: Re: [KEYPROV] My notes from today X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:41:44 -0000 Philip/Ming,=20 We should think through the scenario here...because per discussion last evening, you can only deliver one KeyPackage per DSKSPP exchange.=20 Another point that we discussed towards the end was the that is used to secure the package, do we want that inside the , or outside. Siddharth -----Original Message----- From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Pei, Mingliang Sent: Wednesday, March 25, 2009 11:24 AM To: Philip Hoyer; Pasi.Eronen@nokia.com; keyprov@ietf.org Subject: Re: [KEYPROV] My notes from today It is fine to do this way - the similar thought we used Key for reference. The main change that we need from the discussion is to move Device attributes into Key, and promoto Key up to KeyPackage. It could be simply this change, or further revisit on grouping key usage, policy and data etc within a key package in your email. I incline to do the simple change, which aligns our concept model with DSKPP. - Ming=20 -----Original Message----- From: Philip Hoyer [mailto:philip.hoyer@actividentity.com] Sent: Wednesday, March 25, 2009 11:21 AM To: Pei, Mingliang; Pasi.Eronen@nokia.com; keyprov@ietf.org Subject: RE: [KEYPROV] My notes from today Ming, PIN is interesting again since normally it spans multiple keys and is shared hence the reference mechanism used today.=20 In this sense it might be better to wrap PIN as a separate KeyPackage and refer to it from within PINPolicy Philip -----Original Message----- From: Pei, Mingliang [mailto:mpei@verisign.com] Sent: Wednesday, March 25, 2009 6:15 PM To: Philip Hoyer; Pasi.Eronen@nokia.com; keyprov@ietf.org Subject: RE: [KEYPROV] My notes from today I just add one point that we also discussed and agreed: A key may have multiple "secrets" - for example, a PIN associated with a key in addition to KeyValue. Keypackage means to contain one single key and it can still conceptually cover the case. A keypackage should be able to contain all such related information for a key. It is our data structure choice today in PSKC that we reuse to carry a PIN. But that was a structure choice, not the logic concept. The structure inside Keypackage should allow a key value and PIN. The PIN is conceptually an attribute of the key. The data structure could continue to use or a variant within KeyPackage. KeyPackage can mostly replace the current in PSKC but we need some more structure reorganization for proper fit to handle all three kinds of attributes (device, cryptographic module, and key). - Ming -----Original Message----- From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Philip Hoyer Sent: Wednesday, March 25, 2009 2:36 AM To: Pasi.Eronen@nokia.com; keyprov@ietf.org Subject: Re: [KEYPROV] My notes from today Pasi, I think we are getting to some consensus. I was wondering if Key, KeyAttributes and KeyType need a bit more analysis. I believe that we should explicitly model KeyPolicy e.g. the Policy governing the use of the key, hence this would be: - Usage (encryption, decription, OTP, etc) - permitted dates the key can be used - permitted number of transactions - PINPoliicy - etc Then we have the key and its algorithm There is the concept of static parameters for a specific algorithm for example - IV - OTP length - format produced And then for some algorithm types we have the concept of dynamic values/meta_data, tied to a key for example: - OTP event counter - time drift Now I am not sure if we need to split them out but currently in PSKC we have modeled them separately - dynamic value are under Key.Data (e.g. Key.Data.Counter) - static values are under Key.Usage (e.g. Key.Usage.ResponseFormat) The other point I wanted to make is that the User binding currently can be on a device level AND on a Key level and the Users could be different so maybe we should leave the user under the respective sub elements: ...info about Key Algorithm (under here we could put the current Key.Usage and rename them as algorithm.parameters) Data (dynamic data) Policy ...info about User ...info about Issuer ...info about Cryptographic Module ...info about Device SerialNo Manufacturer ...info about User etc .... .... Philip -----Original Message----- From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Wednesday, March 25, 2009 1:46 AM To: keyprov@ietf.org Subject: [KEYPROV] My notes from today Writing these down before the social event...=20 Key: A logical component that performs symmetric key operations using a Key Value, Key Attributes, and other state.=20 Key Value: The secret value used by a Key. (DSKPP and PSKC treat this as a single key, although there could be some internal structure.) Key Attributes: Set of information that influence how the Key Value will be used, and how the Key can be used. Example: The length of OTP value (for OTP algorithms that support variable length OTPs), date after which the Key should not be used, how access to Key functionality should be controlled (e.g. local PIN code). Key Type: Determines how a Key works: for example, the allowed lengths of the Key Value, the cryptographic operations that can be performed (e.g. OTP computation or challenge-response) and their inputs, outputs, and algorithms; and what Key Attributes can be used. Example: some examples of one-time password Key Types are HOTP [RFC4226], S/Key [RFC1760], and SecurID-AES. In DSKPP and PSKC,=20 Key Types are identified by URIs. Cryptographic Module: A logical component that contains one or more Keys. Can be implemented in hardware or software. Device: The physical device implementing the Cryptographic Module. Example: For hardware Cryptographic Modules, a single Device usually contains only one Cryptographic Module. For software Cryptographic Modules, the Device is the host device (laptop, server, mobile phone, etc.), and can contain multiple=20 Cryptographic Modules. Key Package: A data structure for moving a single Key from one Cryptographic Module to another. Contains data about the Key (e.g. Key Value and Attributes), Cryptographic Module (e.g. source or intended destination Key), Device, Issuer (an organization or party that manages some Keys -- and possibly Cryptographic Modules and/or Devices -- or has some kind of authority over them), and User (user, account, role, or other entity that uses the services provided by Key, or is otherwise associated with it). =20 Key Container: A data structure or file containing one or more Key Packages. These were not discussed, but should be very straightforward: DSKPP Client: The logical entity implementing the client part of DSKPP protocol; communicates with an Cryptographic Module to provision Keys to the Cryptographic Module. In case of Hardware Cryptographic Modules, the DSKPP Client might run on a PC to which the Hardware Cryptographic Module is connected. In case of Software Cryptographic Modules, the DSKPP Client could be part of the same software package as the Cryptographic Module itself, or separate. (The interface between the Cryptographic Module and the DSKPP Client is not specified in this document.) DSKPP Server: The logical entity that communicates with the DSKPP client; usually communicates with a server-side Cryptographic Module so that a corresponding Key (with the same Key Value) exists also on the server side. The interface between the DSKPP Server and the server-side Cryptographic Module is beyond the scope of this document. -------------- ...info about Key ...info about Cryptographic Module ...info about Device ...info about Issuer ...info about User .... .... -------- Best regards, Pasi _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov From mpei@verisign.com Wed Mar 25 15:08:23 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199183A68EF for ; Wed, 25 Mar 2009 15:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 3UuFF-HdfcGy for ; Wed, 25 Mar 2009 15:08:21 -0700 (PDT) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id C1AF63A68A7 for ; Wed, 25 Mar 2009 15:08:21 -0700 (PDT) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n2PLhdcp014259; Wed, 25 Mar 2009 14:43:41 -0700 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 15:09:10 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 25 Mar 2009 15:09:09 -0700 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C90126DAF5@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] My notes from today Thread-Index: Acms6236ZbPN91oQRTiLhHxN0dI8GwAP7zOgABJdnnAAAGbIEAAAAD1QAAcFJ9AAAJcnsA== References: <808FD6E27AD4884E94820BC333B2DB7727F20B4A3F@NOK-EUMSG-01.mgdnok.nokia.com><5BFE9E473DBFC24CA87F18F29B3F0AC403EB73D9@sur-corp-ex-02.corp.ad.activcard.com><3E5A2F1AD44F5E49A74F79AB47C0C0C90126DAD3@mou1wnexmb10.vcorp.ad.vrsn.com><5BFE9E473DBFC24CA87F18F29B3F0AC403EB73E1@sur-corp-ex-02.corp.ad.activcard.com> <3E5A2F1AD44F5E49A74F79AB47C0C0C90126DAD5@mou1wnexmb10.vcorp.ad.vrsn.com> From: "Pei, Mingliang" To: "Bajaj, Siddharth" , "Philip Hoyer" , , X-OriginalArrivalTime: 25 Mar 2009 22:09:10.0627 (UTC) FILETIME=[53047330:01C9AD96] Subject: Re: [KEYPROV] My notes from today X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 22:08:23 -0000 We need a way to let EncryptionKey to accommendate both use cases - single and bulk. If DSKPP has to use KeyPackage instead of KeyContainer with a single keypackage, the encryption key information must be available in KeyPackage. It is a constraint that DSKPP puts on PSKC. I see two options to achieve this: 1. Keep Encryption key in KeyContainer level. Keypackage doesn't need to have any reference. By default, it assumes that the same key is used for encryption. This doesn't allow DSKPP to refer to KeyPackage level. 2. Allow Encryption key in both KeyContainer and KeyPackage level. KeyPackage may have if there is none in the container level. If Keypackage doesn't have an encryption key element, the default is the one defined in the container level. 3. The first KeyPackage contains encryption key information. When more than one keypackage exists in a container, the subsequent Keypackage can refer to the the encryption key in the frist one, or its own. Option 1 is cleaner and more "normative" in my opinion for a standalone PSKC. Option 3 looks optimal for DSKPP use of KeyPackage. There was an idea that the entire payload is encrypted if multiple packages are present. I consider it not consistent with main approach - we would need to handle encryption in two ways. - Ming=20 > -----Original Message----- > From: Bajaj, Siddharth=20 > Sent: Wednesday, March 25, 2009 2:42 PM > To: Pei, Mingliang; Philip Hoyer; Pasi.Eronen@nokia.com;=20 > keyprov@ietf.org > Subject: RE: [KEYPROV] My notes from today >=20 >=20 > Philip/Ming,=20 >=20 > We should think through the scenario here...because per=20 > discussion last evening, you can only deliver one KeyPackage=20 > per DSKSPP exchange.=20 >=20 > Another point that we discussed towards the end was the=20 > that is used to secure the package, do we=20 > want that inside the , or outside. >=20 > Siddharth >=20 > -----Original Message----- > From: keyprov-bounces@ietf.org=20 > [mailto:keyprov-bounces@ietf.org] On Behalf Of Pei, Mingliang > Sent: Wednesday, March 25, 2009 11:24 AM > To: Philip Hoyer; Pasi.Eronen@nokia.com; keyprov@ietf.org > Subject: Re: [KEYPROV] My notes from today >=20 >=20 > It is fine to do this way - the similar thought we used Key=20 > for reference. The main change that we need from the=20 > discussion is to move Device attributes into Key, and promoto=20 > Key up to KeyPackage. It could be simply this change, or=20 > further revisit on grouping key usage, policy and data etc=20 > within a key package in your email. I incline to do the=20 > simple change, which aligns our concept model with DSKPP. >=20 > - Ming=20 >=20 > -----Original Message----- > From: Philip Hoyer [mailto:philip.hoyer@actividentity.com] > Sent: Wednesday, March 25, 2009 11:21 AM > To: Pei, Mingliang; Pasi.Eronen@nokia.com; keyprov@ietf.org > Subject: RE: [KEYPROV] My notes from today >=20 > Ming, > PIN is interesting again since normally it spans multiple=20 > keys and is shared hence the reference mechanism used today.=20 >=20 > In this sense it might be better to wrap PIN as a separate=20 > KeyPackage and refer to it from within PINPolicy >=20 > Philip >=20 > -----Original Message----- > From: Pei, Mingliang [mailto:mpei@verisign.com] > Sent: Wednesday, March 25, 2009 6:15 PM > To: Philip Hoyer; Pasi.Eronen@nokia.com; keyprov@ietf.org > Subject: RE: [KEYPROV] My notes from today >=20 >=20 > I just add one point that we also discussed and agreed: >=20 > A key may have multiple "secrets" - for example, a PIN=20 > associated with a key in addition to KeyValue. Keypackage=20 > means to contain one single key and it can still conceptually=20 > cover the case. A keypackage should be able to contain all=20 > such related information for a key. It is our data structure=20 > choice today in PSKC that we reuse to carry a PIN. But=20 > that was a structure choice, not the logic concept. The=20 > structure inside Keypackage should allow a key value and PIN.=20 > The PIN is conceptually an attribute of the key. The data=20 > structure could continue to use or a variant within=20 > KeyPackage. KeyPackage can mostly replace the current=20 > in PSKC but we need some more structure=20 > reorganization for proper fit to handle all three kinds of=20 > attributes (device, cryptographic module, and key). >=20 > - Ming >=20 > -----Original Message----- > From: keyprov-bounces@ietf.org=20 > [mailto:keyprov-bounces@ietf.org] On Behalf Of Philip Hoyer > Sent: Wednesday, March 25, 2009 2:36 AM > To: Pasi.Eronen@nokia.com; keyprov@ietf.org > Subject: Re: [KEYPROV] My notes from today >=20 > Pasi, >=20 > I think we are getting to some consensus. >=20 > I was wondering if Key, KeyAttributes and KeyType need a bit=20 > more analysis. >=20 > I believe that we should explicitly model KeyPolicy e.g. the=20 > Policy governing the use of the key, hence this would be: >=20 > - Usage (encryption, decription, OTP, etc) > - permitted dates the key can be used > - permitted number of transactions > - PINPoliicy > - etc >=20 > Then we have the key and its algorithm >=20 > There is the concept of static parameters for a specific=20 > algorithm for example > - IV > - OTP length > - format produced >=20 > And then for some algorithm types we have the concept of=20 > dynamic values/meta_data, tied to a key for example: > - OTP event counter > - time drift >=20 > Now I am not sure if we need to split them out but currently=20 > in PSKC we have modeled them separately >=20 > - dynamic value are under Key.Data (e.g. Key.Data.Counter) > - static values are under Key.Usage (e.g. Key.Usage.ResponseFormat) >=20 >=20 > The other point I wanted to make is that the User binding=20 > currently can be on a device level AND on a Key level and the=20 > Users could be different so maybe we should leave the user=20 > under the respective sub elements: >=20 > > > ...info about Key > Algorithm (under here we could put the=20 > current Key.Usage and rename them as algorithm.parameters) > Data (dynamic data) > Policy > ...info about User > ...info about Issuer > ...info about Cryptographic Module > ...info about Device > SerialNo > Manufacturer > ...info about User > etc > > > .... > > > .... > > >=20 >=20 > Philip >=20 > -----Original Message----- > From: keyprov-bounces@ietf.org=20 > [mailto:keyprov-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com > Sent: Wednesday, March 25, 2009 1:46 AM > To: keyprov@ietf.org > Subject: [KEYPROV] My notes from today >=20 > Writing these down before the social event...=20 >=20 > Key: A logical component that performs symmetric key=20 > operations using a Key Value, Key Attributes, and other state.=20 >=20 > Key Value: The secret value used by a Key. (DSKPP and PSKC=20 > treat this as a single key, although there could be some=20 > internal structure.) >=20 > Key Attributes: Set of information that influence how the Key=20 > Value will be used, and how the Key can be used. >=20 > Example: The length of OTP value (for OTP algorithms that support > variable length OTPs), date after which the Key should not be used, > how access to Key functionality should be controlled (e.g. local > PIN code). >=20 > Key Type: Determines how a Key works: for example, the=20 > allowed lengths of the Key Value, the cryptographic=20 > operations that can be performed (e.g. OTP computation or=20 > challenge-response) and their inputs, outputs, and=20 > algorithms; and what Key Attributes can be used. >=20 > Example: some examples of one-time password Key Types are HOTP > [RFC4226], S/Key [RFC1760], and SecurID-AES. In DSKPP and PSKC,=20 > Key Types are identified by URIs. >=20 > Cryptographic Module: A logical component that contains one=20 > or more Keys. Can be implemented in hardware or software. >=20 > Device: The physical device implementing the Cryptographic Module. >=20 > Example: For hardware Cryptographic Modules, a single Device > usually contains only one Cryptographic Module. For software > Cryptographic Modules, the Device is the host device (laptop, > server, mobile phone, etc.), and can contain multiple=20 > Cryptographic Modules. >=20 > Key Package: A data structure for moving a single Key from=20 > one Cryptographic Module to another. Contains data about the=20 > Key (e.g. Key Value and Attributes), Cryptographic Module=20 > (e.g. source or intended destination Key), Device, Issuer (an=20 > organization or party that manages some Keys -- and possibly=20 > Cryptographic Modules and/or Devices > -- or has some kind of authority over them), and User (user,=20 > account, role, or other entity that uses the services=20 > provided by Key, or is otherwise associated with it). > =20 > Key Container: A data structure or file containing one or=20 > more Key Packages. >=20 >=20 > These were not discussed, but should be very straightforward: >=20 > DSKPP Client: The logical entity implementing the client part=20 > of DSKPP protocol; communicates with an Cryptographic Module=20 > to provision Keys to the Cryptographic Module. In case of=20 > Hardware Cryptographic Modules, the DSKPP Client might run on=20 > a PC to which the Hardware Cryptographic Module is connected.=20 > In case of Software Cryptographic Modules, the DSKPP Client=20 > could be part of the same software package as the=20 > Cryptographic Module itself, or separate. (The interface=20 > between the Cryptographic Module and the DSKPP Client is not=20 > specified in this > document.) >=20 > DSKPP Server: The logical entity that communicates with the=20 > DSKPP client; usually communicates with a server-side=20 > Cryptographic Module so that a corresponding Key (with the=20 > same Key Value) exists also on the server side. The interface=20 > between the DSKPP Server and the server-side Cryptographic=20 > Module is beyond the scope of this document. >=20 >=20 > -------------- >=20 > > > ...info about Key > ...info about Cryptographic Module > ...info about Device > ...info about Issuer > ...info about User > > > .... > > > .... > > >=20 > -------- >=20 > Best regards, > Pasi > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www.ietf.org/mailman/listinfo/keyprov >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www.ietf.org/mailman/listinfo/keyprov >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www.ietf.org/mailman/listinfo/keyprov >=20 From anders.rundgren@telia.com Fri Mar 27 00:18:28 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD653A67D2 for ; Fri, 27 Mar 2009 00:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 oGF-vQaYVQqL for ; Fri, 27 Mar 2009 00:18:27 -0700 (PDT) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by core3.amsl.com (Postfix) with ESMTP id 94CAD3A63EC for ; Fri, 27 Mar 2009 00:18:27 -0700 (PDT) Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA9503E85F27 for keyprov@ietf.org; Fri, 27 Mar 2009 08:19:20 +0100 Message-ID: <6D7D66F62BE043EDA1CD35C16DDD8658@AndersPC> From: "Anders Rundgren" To: "KEYPROV" Date: Fri, 27 Mar 2009 08:19:48 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C3_01C9AEB4.CB290820" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.20661 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Subject: [KEYPROV] Security Flaw X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 07:18:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C3_01C9AEB4.CB290820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have discovered a security flaw in certain KEYPROV setups as well as = in KeyGen2. I'm currently researching a countermeasure that may resolve = the problem. Here is a write-up of the security flaw: An established way to perform a secure download is that the client sends = a public key (or public key certificate) to the server which is then = used by the server to wrap either the secret data itself, or a freshly = generated symmetric key which is used for bulk encryption of the secret = payload. The client uses its corresponding private key to unwrap the = encrypted data. To verify the integrity of downloaded data, MACs = (Message Authenticate Codes) are usually added as well. Although the above "works" in the sense that a provider that recognizes = the public key does not have to worry about sending sensitive or secret = data to the wrong party, unfortunately nothing prevents a MITM (Man In = The Middle) from replacing the original encrypted data with something = else including generating proper MACs, since the whole scheme relies on = a single more or less public key, which thus makes the attack go "under = the radar"! Is this a serious limitation? For authentication keys this is probably a = minor snag since a bad key presumably doesn't give you access anywhere, = while fake PINs and PUKs are slightly more worrying. In addition to = imagined or real threats, there is also an "acceptance" problem with = systems having unresolved security issues. Replaced encryption keys = could in fact be disastrous since they typically would reveal secret = data to the attacker while hiding it from the true recipient! Anders ------=_NextPart_000_00C3_01C9AEB4.CB290820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have discovered a security flaw in certain KEYPROV = setups as=20 well as in KeyGen2.  I'm currently researching a countermeasure=20 that may resolve the problem.  Here is a write-up of the = security=20 flaw:

An established way to perform a = secure=20 download is that the client sends a public key (or public key = certificate) to=20 the server which is then used by the server to wrap either the secret = data=20 itself, or a freshly generated symmetric key which is used for bulk = encryption=20 of the secret payload. The client uses its corresponding private key to = unwrap=20 the encrypted data. To verify the integrity of downloaded data, MACs = (Message=20 Authenticate Codes) are usually added as well.

Although the above "works" in the = sense that a=20 provider that recognizes the public key does not have to worry about = sending=20 sensitive or secret data to the wrong party, unfortunately nothing = prevents a=20 MITM (Man In The Middle) from replacing the original encrypted data with = something else including generating proper MACs, since the whole scheme = relies=20 on a single more or less public key, which thus makes the attack go = "under the=20 radar"!

Is this a serious limitation? For=20 authentication keys this is probably a minor snag since a bad key = presumably=20 doesn=92t give you access anywhere, while fake PINs and PUKs are = slightly more=20 worrying. In addition to imagined or real threats, there is also an = "acceptance"=20 problem with systems having unresolved security issues. Replaced = encryption=20 keys could in fact be disastrous since they typically would reveal = secret=20 data to the attacker while hiding it from the true recipient!

Anders

------=_NextPart_000_00C3_01C9AEB4.CB290820-- From mpei@verisign.com Fri Mar 27 18:41:27 2009 Return-Path: X-Original-To: keyprov@core3.amsl.com Delivered-To: keyprov@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C3433A67EC for ; Fri, 27 Mar 2009 18:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 uO7lZeOEB291 for ; Fri, 27 Mar 2009 18:41:13 -0700 (PDT) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id C7ACE3A69C8 for ; Fri, 27 Mar 2009 18:41:13 -0700 (PDT) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n2S1GSxn004514; Fri, 27 Mar 2009 18:16:28 -0700 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 18:42:04 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AF46.65A51043" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Mar 2009 18:42:04 -0700 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C90126DB9D@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <0FE70A085F9375408E93BF8409EB103D074971AE@extlv102.eAladdin.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt Thread-Index: AcmVsDqj/B6j6zRKR2mQCtKzoVhkGwBC86RAAbU8oIACRCn78AABZgJQAAAqJvABZ4Uc0AC/fxow References: <5BFE9E473DBFC24CA87F18F29B3F0AC403EB723A@sur-corp-ex-02.corp.ad.activcard.com> <0FE70A085F9375408E93BF8409EB103D07209089@extlv102.eAladdin.org> <065171DAC4F2674EA8C1142A1AF8E7C315467921@mou1wnexmb10.vcorp.ad.vrsn.com> <065171DAC4F2674EA8C1142A1AF8E7C315467922@mou1wnexmb10.vcorp.ad.vrsn.com> <3E5A2F1AD44F5E49A74F79AB47C0C0C90126D881@mou1wnexmb10.vcorp.ad.vrsn.com> <0FE70A085F9375408E93BF8409EB103D074971AE@extlv102.eAladdin.org> From: "Pei, Mingliang" To: "Andrew Lindell" , , X-OriginalArrivalTime: 28 Mar 2009 01:42:04.0426 (UTC) FILETIME=[659EFEA0:01C9AF46] Cc: Doron Cohen Subject: Re: [KEYPROV] [OATH Technical] FW: WGLC: draft-ietf-keyprov-pskc-02.txt X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 01:41:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AF46.65A51043 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andrew, =20 Yes, we thought of using key derivation to obtain two keys from some discussions this week in IETF. The option to derive a MAC key from KEK itself is considered not a choice because in principle we don't want to use the same key for two purpose - encryption and derivation. Treating pre-shared key as a master key to derive KEK and K_MAC is a feasible choice. =20 When two key derivation is chosen, we would need to define KDF in PSKC, handling both password derived key and pre-shared master key. For password derived key, maybe we can use the same derivation function but different salts respectively for KEK and K_MAC. It is under discussion. Using a different KDF for pre-shared master key may add more complexity than the random chosen K_MAC. The KDF could be simply HMAC of K_master with some different constant string for KEK and K_MAC, for example, KEK =3D HMAC(K_master, "0000") and K_MAC =3D HMAC(K_master, "1111"), = thanking Hugo Krawczyk for the suggestion. Alternatively PSKC can easily pass encrypted K_MAC with KEK in payload. =20 I favor more the random chosen K_MAC for now than the KDF approach for two keys in terms of one approach for both password and pre-shared key case. KDF is good that it doesn't need to pass additional parameter in payload. Comments are appreciated on the choice and best practices in other specifications. =20 Thank you, =20 - Ming ________________________________ From: Andrew Lindell [mailto:Andrew.Lindell@aladdin.com]=20 Sent: Monday, March 23, 2009 11:13 PM To: Pei, Mingliang; oath_technical@v2.listbox.com; keyprov@ietf.org Cc: Doron Cohen Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt =09 =09 Hi Ming, =20 Thank you for your response. One thing however is not clear to me now. Is the hashed key (ValueMAC) encrypted together with the key? If yes, then I agree with you that it's not really a concern. This also solves the problem of integrity (albeit not cryptographically, where a MAC is really needed). However, if the hashed value is not encrypted, then this can be a problem if someone uses a procedure that results in a relatively low entropy key. Although such a procedure within itself is bad, this would make it worse and so it would be better to encrypt the hashed value as well. =20 One other thing, regarding item (1). When two keys cannot be provided, have you thought of using key derivation to obtain two keys from the one. Although you keep the same entropy, this is more cryptographically sound than using the same key for both tasks. =20 Thanks, =20 Andrew =20 From: Pei, Mingliang [mailto:mpei@verisign.com]=20 Sent: Tuesday, March 17, 2009 04:29 To: Pei, Mingliang; oath_technical@v2.listbox.com; keyprov@ietf.org Cc: Andrew Lindell Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt =20 Copying keyprov mailing list... - Ming =20 ________________________________ From: Pei, Mingliang=20 Sent: Monday, March 16, 2009 7:26 PM To: Pei, Mingliang; 'oath_technical@v2.listbox.com' Cc: 'Andrew Lindell' Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt I need to clarify that the strong hash is good when the cleartext to be encrypted is some long random secret bytes. If the value is within some known finite integer values, some simple hash lookup over all possible values will reveal the cleartext itself. =20 Thanks, =20 - Ming =20 ________________________________ From: Pei, Mingliang=20 Sent: Monday, March 16, 2009 7:22 PM To: oath_technical@v2.listbox.com Cc: Andrew Lindell Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt Hi Doron and Andrew, =20 Thank you very much for the review and comments. =20 1. It is actually a working item in the draft per earlier comment. We agree with you that using the same key for MAC and encryption isn't a good practice. We thought of options that allow one to specify a separate MAC key by extending the current definition on the MAC algorithm type. Asking two keys isn't ideal for those pre-shared encryption key devices. In DSKPP, a MAC key was randomly generated and encrypted along with the secret. We have not had deep discussions on this. Thank you for raising the issue, and it will help us to make sure it is addressed in the final version. =20 2. The purpose of the ValueMAC is to serve integrity check of the data. It isn't intended for any sender authentication. On one hand, our initial version simply pass a hash value of the data to be encrypted, for example, ValueMAC =3D SHA_256(cleartext). Note that hashing over ciphertext doesn't serve the purpose. A man-in-the-middle may alter the ciphertext and generate hash accordingly. Therefore it is necessary to calculate it over the cleartext.=20 =20 When HMAC was chosen for the integrity check purpose, we still felt that the hash over the original data was good. The essential argument goes back to the first item: should the MAC key be a separate one. If it is a separate one, the security concern doesn't seem to exist. =20 For simplicity, I consider that SHA_256(cleartext) is fine without requiring complexity in choosing MAC key for HMAC. Using the same key again isn't good. There are other ways to serve the integrity check, for example, encryption is over + . The simpliest is with a strong hash function such as SHA_256. I don't think a strong hash and encrypted value together will reveal the cleartext. =20 Suggestions are welcomed for making this choice. =20 Thank you, =20 - Ming =20 ________________________________ From: Doron Cohen [mailto:doronc@aladdin.com]=20 Sent: Thursday, March 05, 2009 4:58 AM To: oath_technical@v2.listbox.com Cc: Andrew Lindell; oath_technical@v2.listbox.com Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt Hi Philip, =20 Below are a couple of comments I received from Aladdin's Chief Cryptographer, Yehuda (Andrew) Lindell . Yehuda will be glad to provide more clarifications if required. =20 "When algorithms without integrity checks are used, such as AES-128-CBC, a keyed MAC value using the same key as the key encryption key MUST be placed in the element of the element. In this case the MAC algorithm type MUST be set in the element of the element. Implementations of PSKC MUST support HMAC-SHA1 (with the URI of http://www.w3.org/2000/09/xmldsig#hmac-sha1) as the mandatory-to-implement MAC algorithm. =20 [Yehuda Lindell] This is very bad practice. You should not use the same key for different tasks. The solution to this (where an authenticated-encryption scheme is not used) is to use key derivation to obtain two keys from the single one, and then use the first for encryption and the second for the MAC. =20 In section 4.2 the following appears: =20 Additionally, a element, which is populated with a MAC generated from the unencrypted value in case the encryption algorithm does not support integrity checks, MAY be included as a child element. The example shown at Figure 2 illustrates the usage of the element with two child elements, namely and . Both elements carry plaintext value within the child element. =20 [Yehuda Lindell] This says that the MAC is applied to the unencrypted value. This is bad practice (it is not always secure) and it's far better to generate the MAC by applying it to the encrypted ciphertext. In any case, this contradicts what appears below in Section 6.1 (Section 6.1 explicitly states that the MAC is applied to the encrypted value, which is the correct way to work). =20 =20 Best Regards Doron =20 Doron Cohen CTO, Authentication Business Unit Aladdin Knowledge Systems =20 =20 =20 =20 =20 =20 =20 From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Tuesday, February 24, 2009 22:14 To: oath_technical@v2.listbox.com Subject: [OATH Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt =20 Ladies and Gentlemen: Could I invite the participants on the list please to review the PSKC spec as below as the work started in OATH and it would be great to see what you think of it now. =20 Philip =20 ________________________________ From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Monday, February 23, 2009 12:14 PM To: KEYPROV Subject: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt =20 Hi all,=20 this is a KEYPROV Working Group Last Call for comments on=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-02.txt =20 Please send your comments to the list by March 6, 2009.=20 Ciao=20 Hannes & Phillip=20 ________________________________ oath_technical | Archives | Modify Your Subscription =20 =20 =09 =09 ************************************************************************ ************************** The contents of this email and any attachments are confidential. It is intended for the named recipient(s) only. If you have received this email in error please notify the system manager or? the=20 sender immediately and do not disclose the contents to anyone or make copies. ** eSafe scanned this email for viruses, vandals and malicious content ** =09 ************************************************************************ ************************** ________________________________ oath_technical | Archives | Modify Your Subscription=20 =20 =20 =09 ************************************************************************ ************************** The contents of this email and any attachments are confidential. It is intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the=20 sender immediately and do not disclose the contents to anyone or make copies. ** eSafe scanned this email for viruses, vandals and malicious content ** =09 ************************************************************************ ************************** =09 ------_=_NextPart_001_01C9AF46.65A51043 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WGLC: = draft-ietf-keyprov-pskc-02.txt
Hi Andrew,
 
Yes, we thought of using key derivation to = obtain two=20 keys from some discussions this week in IETF. The option to derive a MAC = key=20 from KEK itself is considered not a choice because in principle we don't = want to=20 use the same key for two purpose - encryption and derivation. Treating=20 pre-shared key as a master key to derive KEK and K_MAC is a feasible=20 choice.
 
When two key derivation is chosen, we would = need to define=20 KDF in PSKC, handling both password derived key and pre-shared master = key. For=20 password derived key, maybe we can use the same derivation function but=20 different salts respectively for KEK and K_MAC. It is under discussion. = Using a=20 different KDF for pre-shared master key may add more complexity than the = random=20 chosen K_MAC. The KDF could be simply HMAC of K_master with some = different=20 constant string for KEK and K_MAC, for example, KEK =3D HMAC(K_master, = "0000") and=20 K_MAC =3D HMAC(K_master, "1111"), thanking Hugo Krawczyk for the = suggestion.=20 Alternatively PSKC can easily pass encrypted K_MAC with KEK in=20 payload.
 
I favor more the random chosen K_MAC for now = than the KDF=20 approach for two keys in terms of one approach for both password and = pre-shared=20 key case. KDF is good that it doesn't need to pass additional = parameter in=20 payload. Comments are appreciated on the choice and best practices in = other=20 specifications.
 
Thank you,
 
- Ming

From: Andrew Lindell=20 [mailto:Andrew.Lindell@aladdin.com]
Sent: Monday, March 23, = 2009=20 11:13 PM
To: Pei, Mingliang; oath_technical@v2.listbox.com;=20 keyprov@ietf.org
Cc: Doron Cohen
Subject: RE: = [OATH=20 Technical] FW: [KEYPROV] WGLC:=20 draft-ietf-keyprov-pskc-02.txt

Hi=20 Ming,

 

Thank=20 you for your response. One thing however is not clear to me now. Is = the hashed=20 key (ValueMAC) encrypted together with the key? If yes, then I agree = with you=20 that it’s not really a concern. This also solves the problem of = integrity=20 (albeit not cryptographically, where a MAC is really needed). However, = if the=20 hashed value is not encrypted, then this can be a problem if someone = uses a=20 procedure that results in a relatively low entropy key. Although such = a=20 procedure within itself is bad, this would make it worse and so it = would be=20 better to encrypt the hashed value as well.

 

One=20 other thing, regarding item (1). When two keys cannot be provided, = have you=20 thought of using key derivation to obtain two keys from the one. = Although you=20 keep the same entropy, this is more cryptographically sound than using = the=20 same key for both tasks.

 

Thanks,

 

Andrew

 

From: Pei, = Mingliang=20 [mailto:mpei@verisign.com]
Sent: Tuesday, March 17, 2009=20 04:29
To: Pei, Mingliang; oath_technical@v2.listbox.com;=20 keyprov@ietf.org
Cc: Andrew Lindell
Subject: RE: = [OATH=20 Technical] FW: [KEYPROV] WGLC:=20 draft-ietf-keyprov-pskc-02.txt

 

Copying=20 keyprov mailing list... - Ming

 

From: Pei, = Mingliang=20
Sent: Monday, March 16, 2009 7:26 PM
To: Pei,=20 Mingliang; 'oath_technical@v2.listbox.com'
Cc: 'Andrew=20 Lindell'
Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC: = draft-ietf-keyprov-pskc-02.txt

I=20 need to clarify that the strong hash is good when the cleartext to = be=20 encrypted is some long random secret bytes. If the value is within = some=20 known finite integer values, some simple hash lookup over all = possible=20 values will reveal the cleartext itself.

 

Thanks,

 

-=20 Ming

 

From: = Pei,=20 Mingliang
Sent: Monday, March 16, 2009 7:22 = PM
To:=20 oath_technical@v2.listbox.com
Cc: Andrew=20 Lindell
Subject: RE: [OATH Technical] FW: [KEYPROV] = WGLC:=20 draft-ietf-keyprov-pskc-02.txt

Hi=20 Doron and Andrew,

 

Thank=20 you very much for the review and comments.

 

1.=20 It is actually a working item in the draft per earlier comment. We = agree=20 with you that using the same key for MAC and encryption isn't a = good=20 practice. We thought of options that allow one to specify a = separate MAC=20 key by extending the current definition on the MAC algorithm type. = Asking=20 two keys isn't ideal for those pre-shared encryption key = devices. In=20 DSKPP, a MAC key was randomly generated and encrypted along with = the=20 secret. We have not had deep discussions on this. Thank you for = raising=20 the issue, and it will help us to make sure it is addressed in the = final=20 version.

 

2.=20 The purpose of the ValueMAC is to serve integrity check of the = data. It=20 isn't intended for any sender authentication. On one hand, our = initial=20 version simply pass a hash value of the data to be encrypted, for = example,=20 ValueMAC =3D SHA_256(cleartext). Note that hashing over ciphertext = doesn't=20 serve the purpose. A man-in-the-middle may alter the ciphertext = and=20 generate hash accordingly. Therefore it is necessary to calculate = it over=20 the cleartext.

 

When=20 HMAC was chosen for the integrity check purpose, we still felt = that the=20 hash over the original data was good. The essential argument goes = back to=20 the first item: should the MAC key be a separate one. If it is a = separate=20 one, the security concern doesn't seem to = exist.

 

For=20 simplicity, I consider that SHA_256(cleartext) is fine without = requiring=20 complexity in choosing MAC key for HMAC. Using the same key again = isn't=20 good. There are other ways to serve the integrity check, for=20 example, encryption is over <cleartext> + = <Encrypted(random=20 data) with the cleartext>. The simpliest is = <hash(cleartext)>=20 with a strong hash function such as SHA_256. I don't think a = strong hash=20 and encrypted value together will reveal the=20 cleartext.

 

Suggestions=20 are welcomed for making this choice.

 

Thank=20 you,

 

-=20 Ming

 

From: = Doron Cohen=20 [mailto:doronc@aladdin.com]
Sent: Thursday, March 05, = 2009=20 4:58 AM
To: = oath_technical@v2.listbox.com
Cc: Andrew=20 Lindell; oath_technical@v2.listbox.com
Subject: RE: = [OATH=20 Technical] FW: [KEYPROV] WGLC:=20 draft-ietf-keyprov-pskc-02.txt

Hi=20 Philip,

 

Below=20 are a couple of comments I received from Aladdin’s Chief = Cryptographer,=20 Yehuda (Andrew) Lindell .   Yehuda will be glad to = provide=20 more clarifications if required.

 

“When algorithms=20 without integrity checks are used, such as AES-128-CBC, a keyed = MAC=20 value using the same key as the key encryption key MUST be = placed in the=20 <ValueMAC> element of the <Data> element.  In = this case=20 the MAC algorithm type MUST be set in the <MACAlgorithm> = element=20 of the <KeyContainer> element.  Implementations of = PSKC MUST=20 support HMAC-SHA1 (with the URI of=20 http://www.w3.org/2000/09/xmldsig#hmac-sha1) as the=20 mandatory-to-implement MAC algorithm.

 

[Yehuda=20 Lindell] This is very bad practice. You should not use the same = key for=20 different tasks. The solution to this (where an = authenticated-encryption=20 scheme is not used) is to use key derivation to obtain two keys = from the=20 single one, and then use the first for encryption and the second = for the=20 MAC.

 

In=20 section 4.2 the following appears:

 

Additionally, a =
<ValueMac> element, which is populated with a MAC generated from =
the unencrypted value in case the encryption algorithm does not support =
integrity checks, MAY be included as a child element.  The example =
shown at Figure 2 illustrates the usage of the <Data> element with =
two child elements, namely <Secret> and <Counter>.  =
Both elements carry plaintext value within the <PlainValue> child =
element.

 

[Yehuda=20 Lindell] This says that the MAC is applied to the unencrypted = value.=20 This is bad practice (it is not always secure) and it’s = far better to=20 generate the MAC by applying it to the encrypted ciphertext. In = any=20 case, this contradicts what appears below in Section 6.1 = (Section 6.1=20 explicitly states that the MAC is applied to the encrypted = value, which=20 is the correct way to work).

 

 

Best=20 Regards

Doron

 

Doron=20 Cohen

CTO,=20 Authentication Business Unit

Aladdin=20 Knowledge Systems

 

 

 

 

 

 

 

From: = Philip=20 Hoyer [mailto:philip.hoyer@actividentity.com]
Sent: = Tuesday,=20 February 24, 2009 22:14
To:=20 oath_technical@v2.listbox.com
Subject: [OATH = Technical] FW:=20 [KEYPROV] WGLC:=20 draft-ietf-keyprov-pskc-02.txt

 

Ladies=20 and Gentlemen:

Could=20 I invite the participants on the list please to review the PSKC = spec as=20 below as the work started in OATH and it would be great to see = what you=20 think of it now.

 

Philip

 

From:=20 keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On = Behalf=20 Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: = Monday,=20 February 23, 2009 12:14 PM
To: = KEYPROV
Subject:=20 [KEYPROV] WGLC:=20 draft-ietf-keyprov-pskc-02.txt

 

Hi=20 all,

this is a=20 KEYPROV Working Group Last Call for comments on
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-02.txt<= /SPAN>=20

Please=20 send your comments to the list by March 6, 2009. =

Ciao=20
Hannes=20 & Phillip

oath_technical=20 | Archives=20 | Modify=20 Your Subscription

 


***************************************************= ***********************************************
The=20 contents of this email and any attachments are = confidential.
It is=20 intended for the named recipient(s) only.
If you have = received this=20 email in error please notify the system manager or? the =
sender=20 immediately and do not disclose the contents to anyone or make=20 copies.
** eSafe scanned this email for viruses, vandals and=20 malicious content=20 = **
*******************************************************************= *******************************

oath_technical=20 | Archives=20 | Modify=20 Your Subscription

 


****************************************************= **********************************************
The=20 contents of this email and any attachments are confidential.
It is = intended=20 for the named recipient(s) only.
If you have received this email in = error=20 please notify the system manager or  the
sender immediately = and do=20 not disclose the contents to anyone or make copies.
** eSafe = scanned this=20 email for viruses, vandals and malicious content=20 = **
*******************************************************************= *******************************
------_=_NextPart_001_01C9AF46.65A51043--