From keyprov-bounces@ietf.org Mon Jan 5 09:11:39 2009 Return-Path: X-Original-To: keyprov-archive@optimus.ietf.org Delivered-To: ietfarch-keyprov-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EFF13A6849; Mon, 5 Jan 2009 09:11:39 -0800 (PST) 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 396B73A6856 for ; Mon, 5 Jan 2009 09:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_28=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 91d9AvM5Vodr for ; Mon, 5 Jan 2009 09:09:26 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 4CC4C3A63D2 for ; Mon, 5 Jan 2009 09:09:25 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n05H9BMK026907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 12:09:11 -0500 (EST) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si04.isus.emc.com (Tablus Interceptor); Mon, 5 Jan 2009 11:47:14 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n05H99li020041; Mon, 5 Jan 2009 12:09:09 -0500 (EST) From: robert.philpott@rsa.com Received: from CORPUSMX40B.corp.emc.com ([10.254.64.48]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 12:09:08 -0500 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_01C96F58.51FA35AD" Date: Mon, 5 Jan 2009 12:08:39 -0500 Message-ID: <51F3EFC7CE76EC4D99762C23364493E6F07C4E@CORPUSMX40B.corp.emc.com> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] DeviceBinding ? Thread-Index: AclhzbAC4I5xzvSORfemUtRXWsbk5wNii00Q References: To: , X-OriginalArrivalTime: 05 Jan 2009 17:09:08.0810 (UTC) FILETIME=[5276EAA0:01C96F58] X-RSA-Inspected: yes X-RSA-Classifications: X-RSA-Action: allow Subject: Re: [KEYPROV] DeviceBinding ? 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: , Sender: keyprov-bounces@ietf.org Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C96F58.51FA35AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry for the delay in responding to this. There was a discussion on the list back in July describing the need for this element and why existing functionality is inadequate. Rob Philpott=20 RSA, the Security Division of EMC Senior Technologist | e-Mail: robert.philpott@rsa.com | Office: (781) 515-7115 | Mobile: (617) 510-0893 > -----Original Message----- > From: keyprov-bounces@ietf.org [mailto:keyprov-bounces@ietf.org] On Behalf Of > Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Friday, December 19, 2008 6:34 AM > To: keyprov@ietf.org > Subject: [KEYPROV] DeviceBinding ? >=20 > I have a question regarding the following element: >=20 > " > >=20 > This element carries the identifier that can be used to bind keys to the > device or class of device. When loading keys into a device, this > identifier can be checked against information obtained from the device > to ensure that the correct device or class of device is being used. > " >=20 > I am not sure about the purpose of the element and what is actually in > there that makes it different from the already provided PSKC > functionality. >=20 > Ciao > Hannes >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www.ietf.org/mailman/listinfo/keyprov ------_=_NextPart_001_01C96F58.51FA35AD Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MIMEOLE: Produced By Microsoft Exchange V6.5 Received: from corpussmtp2.corp.emc.com ([128.221.14.146]) by CORPUSMX10A.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 07:56:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from mexforward.lss.emc.com ([10.254.145.13]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 07:56:05 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m6EBu3dF014358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 07:56:04 -0400 (EDT) Received: from igw.emc.com (gryphon.lss.emc.com [168.159.216.14]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m6EBu2mP023306; Mon, 14 Jul 2008 07:56:02 -0400 (EDT) Received: from mail170-sin-R.bigfish.com (mail-sin.bigfish.com [207.46.51.74]) by igw.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m6EBtxrA015339; Mon, 14 Jul 2008 07:56:00 -0400 Received: from mail170-sin (localhost.localdomain [127.0.0.1]) by mail170-sin-R.bigfish.com (Postfix) with ESMTP id BC8EA1590249; Mon, 14 Jul 2008 11:55:58 +0000 (UTC) Received: by mail170-sin (MessageSwitch) id 1216036558355316_13884; Mon, 14 Jul 2008 11:55:58 +0000 (UCT) Received: from frhub1.activcard.fr (frhub1.activcard.fr [91.151.120.133]) by mail170-sin.bigfish.com (Postfix) with ESMTP id 8B6F0458050; Mon, 14 Jul 2008 11:55:55 +0000 (UTC) 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 6FF6825ED46; Mon, 14 Jul 2008 13:56:01 +0200 (CEST) Content-class: urn:content-classes:message Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC - no more name value pairs Date: Mon, 14 Jul 2008 06:56:00 -0500 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC40203F17E@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] [pskc] Latest draft of PSKC - no more name value pairs Thread-Index: Acihb52vIXPZfM+dQBGaWxrT4r5ocAAVy7xQAHs9/BAAB0GJoAAC0jWgARViyUAASBMeYAFfxKKAAAGFK/UAAAvvgANQaPGwAZRV6yADujT6IAG6oWTwATCmQMAA2/9+cAAaOCvwAARo/kAAAmN1MABi6N2wAMd0K8A= References: <9ED76AB595E4944BB33D8998DE448D110160C92D@CORPUSMX10B.corp.emc.com><5BFE9E473DBFC24CA87F18F29B3F0AC40203F0D3@sur-corp-ex-02.corp.ad.activcard.com> <5BFE9E473DBFC24CA87F18F29B3F0AC40203F105@sur-corp-ex-02.corp.ad.activcard.com> <5BFE9E473DBFC24CA87F18F29B3F0AC40203F12D@sur-corp-ex-02.corp.ad.activcard.com> <5BFE9E473DBFC24CA87F18F29B3F0AC40203F154@sur-corp-ex-02.corp.ad.activcard.com> <3E5A2F1AD44F5E49A74F79AB47C0C0C9DF4431@mou1wnexmb10.vcorp.ad.vrsn.com> <5BFE9E473DBFC24CA87F18F29B3F0AC40203F157@sur-corp-ex-02.corp.ad.activcard.com> From: To: , , , , , Cc: Rob, Please see comments inline [PH2] =20 Thanks again for all your help, =20 Philip =20 ________________________________ From: robert.philpott@rsa.com [mailto:robert.philpott@rsa.com]=20 Sent: Thursday, July 10, 2008 9:33 PM To: Philip Hoyer; mpei@verisign.com; SMachani@diversinet.com; = Hannes.Tschofenig@gmx.net; pbaker@verisign.com; andrea.doherty@rsa.com Cc: keyprov@ietf.org Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC - no more name value = pairs =20 Hi folks, =20 Sorry I didn't get this out last night. I've continued the dialog below = (some content was snipped to shorten the message)... Sorry for the = length - I'm trying to provide sufficient context around our use cases = to justify the suggestions. =20 Cheers, =20 Rob Philpott=20 RSA, the Security Division of EMC Senior Technologist | e-Mail: robert.philpott@rsa.com | Office: (781) = 515-7115 | Mobile: (617) 510-0893 =20 From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Tuesday, July 08, 2008 8:16 AM To: Pei, Mingliang; Philpott, Robert; SMachani@diversinet.com; = Hannes.Tschofenig@gmx.net; Hallam-Baker, Phillip; Doherty, Andrea Cc: keyprov@ietf.org Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC - no more name value = pairs =20 Ming do you think we should add 'class' in DeviceInfo ? [RSP] I really would prefer not using the name "class" for the element = as that only solves half of our use case. The purpose of the element we = need is to have a single item in the device description of the PSKC = instance document that can be used to match against a characteristic of = the device to ensure that the keys are being loaded on the correct = device or class of device (sorry for the long sentence :-)). =20 =20 You suggested below that the combination of and = should identify a specific device and that adding a class = element could then identify a class of device. =20 =20 First, + are inadequate for our "specific device" = use case. There are numerous devices (e.g. many phones) where we just = cannot programmatically retrieve the device serial number. For example, = I have a Verizon WinMobile phone that has a unique serial number printed = on it. However, I cannot obtain that value from a WinMobile app. =20 =20 The use case I need to satisfy is when an admin provisions a key to me = but our policy mandates that the key can only be loaded on my specific = phone. I thus need my application to verify that when I try to load the = key into the device, that it truly is the right device. Now if I gave = the admin the serial number from the phone, the app can't verify it. = But I might be able to obtain the phone's IMEI number or have the app = show me some other unique value. I could then provide this value when = requesting my key and the admin would put it in the instance = document and my app could verify it when loading the key. =20 While it would be feasible to put this identifier in the SerialNo = element (even though it's not the serial number), I still have the = "class" use case to deal with. If you provide a separate = element, we then will need yet another attribute or element to indicate = which of the 2 options should be enforced when loading a key since both = and the + combination could appear in the = document. For us, it can only be one of the choices but we can't make = that an arbitrary choice; it has to be based on an enterprise policy. =20 =20 This is a critical capability to us. Thus, we are requesting a single = element to identify the restriction information. Since we are "binding" = a key to either a device or to a device class with this information, I = previously suggested calling it either or = . Perhaps a better name would be simply = . This would go into the definition. The = description for the spec would be as follows: =20 * (OPTIONAL), the identifier that can be used to = bind keys to the device or class of device. When loading keys into a = device, this identifier can be checked against information obtained from = the device to ensure that the correct device or class of device is being = used. =20 See comment from Robert below in the email. =20 Philip =20 [PH2] understood and added to submitted spec =20 [RSP] ________________________________ 3. Shouldn't the "KeyId" attribute in the KeyType type also be of = type xs:ID? It is currently defined as xs:string? If this was = intentional, I am quite confused as to the reason for using xs:string. a. Assuming KeyId should be of type xs:ID (and renamed to simply = "Id"), then the PINKeyId attribute in the PINPolicyType type (pending #1 = above) and the MasterKeyId attribute in KeyPropertiesType and KeyType = types would need to be of type xs:IDREF. These attributes are described = to be unique references to keys. [PH] No it can't be of type xs:ID becaue KeyId is actually what you = refer further down as the unique serial number of the keys. [RSP] I suspected that might be the case. However, based on my = experience with a number of other XML-based protocols, I strongly = recommend separating the mechanism of identifying a blob of XML in an = instance document (for which xs:ID and xs:IDREF are very useful) from = the serial numbers that tie the blob to information managed by external = systems. That is, it is generally not a good idea to overload an = attribute to serve double-duty. IMO that's just a cleaner content model. = The ID/IDREF attributes provide formal semantics for defining/referring = to the XML blobs. A "serial number" string does not. Also, it seems to = me that the serial number of a key is no different from a serial number = of a device in that it's info about the key itself, not the XML blob = representing the key. Yet you didn't use the ID attribute of the device = as the serial number of the device. Thus the current approach is = internally inconsistent. So, I still recommend: * In , change to * Since refers to a specific in the instance = document, in , change to =20 For , I am assuming that the master key will also always be = present in the instance document (it's not clear in the spec). If it is = always present, then in and , change = to = . = If, however, the key being referred to is possibly external to the = instance document, then this element should be left alone, but the = description should state that the value refers to an externally-defined = key with a that matches the value. =20 Finally, in add I think it should be an optional element (since we would now have the = xs:ID that can be used to refer to it), although I could be convinced it = should be mandatory. The description would be: * (OPTIONAL), a unique and global identifier of the = symmetric key. The identifier is defined as a string of alphanumeric = characters. =20 [PH2] I understand that there is obviously a confusion here about = semantics and especially with the referral of PIN Key there is a double = use of an external unique identifier (BTW some people do not agree with = the term KeySerialNumber because it somehow makes people think of a = series or continuous number whereas unique keyId could be random. I left = this for now since there is alignment with DSKPP and alos too kuch work = but this is an issue that should be discussed at IETF before we finalise = the spec. The MasterKeyId is external to the document hence left alone. = I added some more I added some text that hoipefully should make it clear = that these are external identifiers. =20 [RSP] =20 5. I personally think the ability to override settings in the = element with specific values defined in the = element might be overkill and could create more opportunities for = implementation bugs. My first preference would be to just define = standalone elements and ONLY allow references from the = elements via the IDREF mechanism. My second preference is to = simply have the element directly embed a element = that is of type KeyPropertiesType and eliminate the use of the IDREF. I = can live with it as is, but do think it over-complicates processing.=20 [PH] the main use for Keyproperties is for bulk provisioning where many = keys share same properties. Hence the model of being able to not have to = repeat the common properties in the same instance. The override is = something that I believe makes sense in this scenario. Assume you are = carrying thousands of keys that share the same properties but a few have = different values so you allow an instance to set a specific value for = something that is already contained in the shared properties. I share = your concern for the support of keyproperties all together. I believe = that many implementations will not implement support for keyproperties = at all. I am less concerned about the override. [RSP] You convinced me; As I said, I can live with the override = mechanism and also realized we have a use case that it can solve. =20 6. In the DeviceInfoType, I believe that the element = should be optional. I know of devices where you cannot discover the = actual serial number of the specific device (e.g. it is embedded in a = larger platform). But I still might desire to include some of the other = device info in the declaration. To do this, I'd have to include a dummy = value for , which IMO is a bad idea. [PH] after long discussions we narrowed down a universal (multiple = manufacturers) way to uniquely identify the device to the combination of = Manufacturer + SerialNo. This is the same as in the certificate world = the use of IssuerDN and serial number uniquely identifies a certificate. = To enforce this combined key Manufacturer and SerialNo are Mandatory. = If you do not have a 'device' per se now that I clarified the KeyId is = the SerialNo of the key you can use the same value for the SerialNo of a = virtual device.=20 [RSP] I'm not sure I understand. In our use case, we have a real, = physical device (not a virtual one), but my physical device cannot = provide me (programmatically) with the device serial number. And my = physical device can hold multiple keys. So I can't use the KeyId of one = of the keys as the serial number of the device... unless you are = suggesting that I create a virtual device for every key that I want to = load into my physical device. This just doesn't make sense to me. =20 In order to put the info into the instance document, the = value has to get entered into the provisioning system that creates the = document. As I said, we have run into quite a few devices where we can't = obtain the device serial number at all or can only obtain it = programmatically with elevated user privs. Examples include my = WinMobile phone, the TPM device on my laptop, and many secure USB flash = drives. If I can't find/display the serial number, it can't be = transferred into the provisioning system to be associated with the = element that holds my keys. Thus, I still believe = should be an optional element. =20 If you adopt our request to include an element in called = (as described above), then I can live with having a = required serial number element here. In cases where we don't know the = serial number, we'll just throw in a dummy value. =20 [RSP] =20 8. I'm not sure I understand why the element is part of = the DeviceType type definition. In our environment, a key is typically = aligned with a single user ID. Consider a scenario where a = holds the keys I will use across multiple applications = where I have been assigned different user ID's. If I use a single = device to hold all of my keys, I can't do this. I thus would prefer to = see the element become part of the KeyPropertiesType type. I = don't think I understand the use case for having it be part of the = device definition. [PH] The userId represents the information of the binding of a physical = device to a user. The userId here is more to do with the concept of a = global UserId rather than the username for a specific application. I = understand your use case but was wondering if this is not slightly out = of scope of PSKC. The concept of UserId to application Username mapping = is covered more in something like SPML. I think the concept of which = key/device can be used for which application is something that we should = leave for this version of the spec. [RSP] Hmmm... I don't think this is quite right. We don't typically = think of binding a device to a single "UserId"; We bind a device to a = "user" (it's owner) or even multiple users (e.g. a multi-user = workstation on a shop floor). A "UserId" typically binds a "user" to a = specific account in an authentication system/application. Consider a = user that has multiple accounts on multiple systems in an enterprise and = they want to use the same device to hold all of the keys for those = accounts. They may of course have different UserId's for each of those = accounts/keys. The enterprise provisioning system could certainly use = SPML to provision the user's accounts (i.e. UserId's) and keys into the = multiple systems/applications. SPML is intended for provisioning this = info into those systems. But to provision the user's keys into the = device, they will use PSKC. Under the current PSKC, the provisioning = system won't know which UserId to use when creating the PSKC instance = document for the . =20 =20 Next, when the user wants to access one of the enterprise systems, they = will access their device and need to choose one of the keys. In our = experience, this is best facilitated by associating a "friendly name" = with each key so they can readily pick the one they need. Once they = choose a key, the associated with the key can then be provided = to the system as part of the authentication. So, I'm not talking about = bringing application-style provisioning into PSKC. I'm simply = associating the user id to which the key pertains with the = element. A single with a and credential might be used = across many applications. But if I have different sets of keys, I want = to know what the user id is that it relates to. =20 So, my suggestion is to allow BOTH associating an optional user name = (e.g. , not ) to a device AND associating an optional = for each key: =20 In , change: To The description should be shortened to: * (OPTIONAL), identifies the owner or the user of the = device. I see no reason to place format constraints on this value as is = currently described using RFC4514. =20 In , add: with a description of: * (OPTIONAL), identifies the user account (e.g. username = or user id) to which the key is assigned. The value MAY be a string = representation of a Distinguished Name as defined in [RFC4514]. For = example "UID=3Djsmith,DC=3Dexample,DC=3Dnet". In systems where unique = user Ids are used the string representation 'UID=3D[uniqueId]' SHOULD be = used. =20 Note that IMO, the use of "UID=3D[uniqueId]" should not be mandated = (i.e. MUST). It's use might help interoperability, but if the = (potentially constrained) client devices just need the user id value, = we'd be forcing them to parse the value to pull out the ID and I just = don't think that should be mandated. =20 Also please consider the concept where keys can be tied to more than one = user (role certs or attribute certs are examples) one could eve envisage = having the same OTP key for multiple users in an environment where the = OTP key protects access to a shared collaboration space (although if = provisioning of an individual key is relatively cheap the it makes no = sense to share an single access key).=20 Absolutely. But the alternative I suggest supports this as well in = addition to supporting the use case I described. =20 =20 [PH2] agree with proposed changes but I am maintaining the format = recommendation for User for interoperability (I changed the MUST to = SHOULD though) =20 [RSP] =20 *** RE: 3. Add additional elements under KeyData based on input from Rob = Philpot =20 The additions below are not just in KeyData: 1. I mentioned this in my previous comments, but I still don't = understand why the spec-defined elements currently listed under the = element need to be nested under . They are well-known = properties of the so why not just list them as child = elements? For example, I don't consider to be any = different than or w.r.t. the keys = properties, so why is one nested under and the others are not. = IMO, , if it is needed at all, should just be for extensions. = Note that my preference would be to not use "Data" at all and just use = the mechanism I describe below. [PH] I tried to explain that everything under Data has a common = structure (e.g, PLainValue and EncryptedValue) and that only those under = can be encrypted. This makes parsing in constraint environment = easier, for example ona smarft card applet where full XML parsers are = not available) (e.g. string search until one finds and then = proceed).=20 [RSP] I understand that point, but I strongly believe that this approach = makes processing more difficult, especially for constrained = environments. IMO there is an alternative that is better for both = constrained and unconstrained environments.=20 =20 For example, in our environment, we would never encrypt a = , so our would just be a value in a = element. But in the current scheme, you say we would = search for and proceed from there. That means then searching = for , then parsing for , then getting the = xs:int value. Yes, I could perhaps skip the search for and look = directly for , but the other parsing is still required.=20 =20 I contend that if was defined outside of with a = type=3D"xs:int", then I could simply search for and then = grab the xs:int value. This is much simpler in a constrained = environment. And in environments where I do have an XML parser, this = structure is even easier to deal with. =20 Also, at least in our use cases, we would never need to encrypt