[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [KEYPROV] My notes from today

To: "Bajaj, Siddharth" <SBajaj at verisign.com>, "Philip Hoyer" <philip.hoyer at actividentity.com>, <Pasi.Eronen at nokia.com>, <keyprov at ietf.org>
Subject: Re: [KEYPROV] My notes from today
From: "Pei, Mingliang" <mpei at verisign.com>
Date: Wed, 25 Mar 2009 15:09:09 -0700
Delivered-to: keyprov at core3.amsl.com
In-reply-to: <F4E86EE3B25D5B4686A74658EB3593E13E4923 at mou1wnexmb03.vcorp.ad.vrsn.com>
List-archive: <http://www.ietf.org/mail-archive/web/keyprov>
List-help: <mailto:keyprov-request@ietf.org?subject=help>
List-id: "Provisioning of Symmetric Keys \(keyprov\)" <keyprov.ietf.org>
List-post: <mailto:keyprov@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/keyprov>, <mailto:keyprov-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/keyprov>, <mailto:keyprov-request@ietf.org?subject=unsubscribe>
References: <808FD6E27AD4884E94820BC333B2DB7727F20B4A3F at NOK-EUMSG-01.mgdnok.nokia.com><5BFE9E473DBFC24CA87F18F29B3F0AC403EB73D9 at sur-corp-ex-02.corp.ad.activcard.com><3E5A2F1AD44F5E49A74F79AB47C0C0C90126DAD3 at mou1wnexmb10.vcorp.ad.vrsn.com><5BFE9E473DBFC24CA87F18F29B3F0AC403EB73E1 at sur-corp-ex-02.corp.ad.activcard.com> <3E5A2F1AD44F5E49A74F79AB47C0C0C90126DAD5 at mou1wnexmb10.vcorp.ad.vrsn.com> <F4E86EE3B25D5B4686A74658EB3593E13E4923 at mou1wnexmb03.vcorp.ad.vrsn.com>
Thread-index: Acms6236ZbPN91oQRTiLhHxN0dI8GwAP7zOgABJdnnAAAGbIEAAAAD1QAAcFJ9AAAJcnsA==
Thread-topic: [KEYPROV] My notes from today

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 <EncryptionKey> 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 

> -----Original Message-----
> From: Bajaj, Siddharth 
> Sent: Wednesday, March 25, 2009 2:42 PM
> To: Pei, Mingliang; Philip Hoyer; Pasi.Eronen at nokia.com; 
> keyprov at ietf.org
> Subject: RE: [KEYPROV] My notes from today
> 
> 
> Philip/Ming, 
> 
> We should think through the scenario here...because per 
> discussion last evening, you can only deliver one KeyPackage 
> per DSKSPP exchange. 
> 
> Another point that we discussed towards the end was the 
> <EncryptionKey> that is used to secure the package, do we 
> want that inside the <KeyPackage>, or outside.
> 
> Siddharth
> 
> -----Original Message-----
> From: keyprov-bounces at ietf.org 
> [mailto:keyprov-bounces at ietf.org] On Behalf Of Pei, Mingliang
> Sent: Wednesday, March 25, 2009 11:24 AM
> To: Philip Hoyer; Pasi.Eronen at nokia.com; keyprov at 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 
> 
> -----Original Message-----
> From: Philip Hoyer [mailto:philip.hoyer at actividentity.com]
> Sent: Wednesday, March 25, 2009 11:21 AM
> To: Pei, Mingliang; Pasi.Eronen at nokia.com; keyprov at 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. 
> 
> 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 at verisign.com]
> Sent: Wednesday, March 25, 2009 6:15 PM
> To: Philip Hoyer; Pasi.Eronen at nokia.com; keyprov at 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 <Key> 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 <Key> or a variant within 
> KeyPackage. KeyPackage can mostly replace the current 
> <Device> 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 at ietf.org 
> [mailto:keyprov-bounces at ietf.org] On Behalf Of Philip Hoyer
> Sent: Wednesday, March 25, 2009 2:36 AM
> To: Pasi.Eronen at nokia.com; keyprov at 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:
> 
> <KeyContainer>
> <KeyPackage>
> ...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
> </KeyPackage>
> <KeyPackage>
> ....
> </KeyPackage>
> <KeyPackage>
> ....
> </KeyPackage>
> </KeyContainer>
> 
> 
> Philip
> 
> -----Original Message-----
> From: keyprov-bounces at ietf.org 
> [mailto:keyprov-bounces at ietf.org] On Behalf Of Pasi.Eronen at nokia.com
> Sent: Wednesday, March 25, 2009 1:46 AM
> To: keyprov at ietf.org
> Subject: [KEYPROV] My notes from today
> 
> Writing these down before the social event... 
> 
> Key: A logical component that performs symmetric key 
> operations using a Key Value, Key Attributes, and other state. 
> 
> 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, 
>    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 
>    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).
>   
> 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.
> 
> 
> --------------
> 
> <KeyContainer>
> <KeyPackage>
> ...info about Key
> ...info about Cryptographic Module
> ...info about Device
> ...info about Issuer
> ...info about User
> </KeyPackage>
> <KeyPackage>
> ....
> </KeyPackage>
> <KeyPackage>
> ....
> </KeyPackage>
> </KeyContainer>
> 
> --------
> 
> Best regards,
> Pasi
> _______________________________________________
> KEYPROV mailing list
> KEYPROV at ietf.org
> https://www.ietf.org/mailman/listinfo/keyprov
> 
> _______________________________________________
> KEYPROV mailing list
> KEYPROV at ietf.org
> https://www.ietf.org/mailman/listinfo/keyprov
> 
> _______________________________________________
> KEYPROV mailing list
> KEYPROV at ietf.org
> https://www.ietf.org/mailman/listinfo/keyprov
>

References:
- [KEYPROV] My notes from today
  - From: Pasi.Eronen
- Re: [KEYPROV] My notes from today
  - From: Philip Hoyer
- Re: [KEYPROV] My notes from today
  - From: Pei, Mingliang
- Re: [KEYPROV] My notes from today
  - From: Philip Hoyer
- Re: [KEYPROV] My notes from today
  - From: Pei, Mingliang
- Re: [KEYPROV] My notes from today
  - From: Bajaj, Siddharth

Prev by Date: Re: [KEYPROV] My notes from today
Next by Date: [KEYPROV] webinar on the Key Management Interoperability Protocol (KMIP) being introduced in OASIS
Previous by thread: Re: [KEYPROV] My notes from today
Next by thread: [KEYPROV] New proposal od PSKC schema based on discussions at IETF and terminology alignment
Index(es):
- Date
- Thread