KEYPROV Minutes (Andrea Doherty)

KEYPROV minutes (Andrea Doherty) 6-7 February 2008 IETF Interim Meeting

IEEE P1619.3 Status Update and Discussion, Matt Ball  Very informative liaison presentation  Refer to slides located at http://www.tschofenig.com/twiki/bin/view/KeyProv/KeyprovInterim2008

Dynamic Symmetric Key Provisioning Protocol (DSKPP) --- Discussion  Overview of changes between draft -01 and -02, Andrea Doherty o General view was that this latest draft is cleaner and more readable. Decision is to move forward using -02 as a base.  Changes to the -02 draft that were agreed to: o Re-phrase Usage Scenario, “Session Time-Out Policy”, Section 1.1.3 to make it clearer o Re-phrase Usage Scenario, “Outsource Provisioning”, Section 1.1.4 so that it is less about a deployment scenario, and more about the need for user authentication within the protocol. o The Object Model, Section 1.2, includes “Key Container”, which is a term that creates confusion with meaning of “Key Container” in the PSKC draft because the latter can support multiple keys whereas DSKPP does not. To avoid confusion, rename term “Key Container” to “Key Package” throughout the DSKPP document. o In “Determining which Protocol Variant to Use”, Section 1.4: . Remove references to “near real-time communication”, and “workflow approval process” as justifications for the two-pass protocol (also found in Section 1.0) . Do mention joint key control . Fix typo on 4th bullet in Sec 1.4.2. . Change term “transport key” to “manufacturing key”, and add to Definitions Section (2.2). . Note that ability to support pre-existing (legacy) keys is a key differentiator between four- and two-pass. . Make clear which design aspects are common to 4- and 2-pass protocol variants, e.g., Algorithm Agility o Add definitions of individual keys to Section 2.2, “Definitions”. Include K_PROV. Be clear in the document about how K_MAC and K_MAC’ are derived. o Rework Section 3.3, “User Authentication”: . Remove heading “User Authentication”. . Rename Section 3.3.1, “Device Identifier” to “Device Identification” and make it its own Section heading (i.e., Section 3.3), rather than a Sub- Section of “Client Authentication”. . Rename “Authentication Data” to “User Authentication” and make it its own heading (Section 3.4) incorporating text from previous Section 3.3. . Cleanup description of Authentication Code, including conformance requirements as per Magnus’s comments. o Move Section 3.5, “Encryption of Pseudorandom Nonces Sent from the DSKPP Client” to the section on the Four-Pass Protocol since the contents only relate to that variant. o Rename “Extensibility”, Section 5.0, to “Protocol Extensions”, and explain why the two extension types are important? For what would we expect them to be used? Also explain how the protocol is extended in general. o Section 9.6.5, “Key Protection in the Two-Pass Passphrase Profile”, mention dependence on the security of the key package.

1 o Rename “Additional Considerations” (Section 9.6) to “Miscellaneous Considerations”. o Review status codes and make sure list is complete. o IANA Considerations are incomplete (Section 11). Hannes to discuss this with IANA folks and make a recommendation for re-phrasing of the section.  Closed all open issues (refer to http://www.tschofenig.com/twiki/bin/viewfile/KeyProv/KeyprovInterim2008? rev=1;filename=DSKPP_PSKC_Issues_updated.xls ) and the Issue Tracker (http://www.tschofenig.com:8080/keyprov ) o Issue 9 – Decision was that DSKPP will rely on key container formats for the Key Protection Profiles, rather than duplicating that work (i.e., action is to remove Key Protection Profiles, Section 3.2.2, from the DSKPP document, and make sure that the profiles are completely covered in the PSKC and ASN.1 documents). o Issue 20 – Decision was to not maintain a separate schema document. Rather, the DSKPP and PSKC document should reference D. Eastlake document (draft- eastlake-additional-xmlsec-uris-00.txt), and register additional URIs (e.g., OTP algorithms). Hannes will chat with Donald Eastlake about Algorithm URIs. He will also ask IANA will it is possible to post the URIs on their Web site. . An outcome of this is that the PSKC and ASN.1 documents should define requirements for mandatory to implement algorithms. . The ASN.1 document should add algorithm identifiers in alignment with PSKC. o Issue 30 – Decision was to express serial number as a string. o Issue 32 – Agreed on conformance requirements: . DSKPP Servers:  MUST implement the four-pass variant of the protocol  MUST implement the two-pass variant of the protocol  MUST support user authentication  Key Derivation Function o MUST support the DSKPP-PRF-AES DSKPP-PRF realization o MUST support the DSKPP-PRF-SHA256 DSKPP-PRF realization  Encryption (for symmetric key operations of the client nonce in 4-pass) o MUST support encryption using the mechanism described in Section 3.5.  Encryption (for symmetric key operations; key transport) o MUST support AES-CBC-128  Encryption (for asymmetric key operations) o MUST support RSA Encryption Scheme  Integrity / KDF MAC o MUST support HMAC-SHA256 o MUST support AES-CMAC-128  Key Packages o MUST implement the PSKC key package [REF]. All three PSKC Key Transport, Key Wrap, and Passphrase- Based Key Wrap protection profiles MUST be implemented (Section 3.2) o MAY implement the ASN.1 key package [REF]. . DSKPP clients need to support either the two-pass or the four-pass variant of the protocol. DSKPP clients must fulfill all requirements listed for DSKPP Servers (beginning with the third bullet).

2 o Issue 33 – See update to the -02 draft regarding the usage scenario for TLS. Decision was to recommend use of TLS. o Issue 34 – The section on the Authentication Code Format (3.3.2.1) was discussed and re-worded as follows: "The AC MUST contain a client identifier and a password. The checksum element is optional and is generated by the issuing server and sent to the user as part of the AC. When the user enters the AC the typed password is verified with the checksum to ensure it is correctly entered by the user. TBD: Checksum algo" o Issue 35 - -02 version already incorporated changes agreed to at IETF-70 meeting: elementDefault changed to qualified, and removed use of schemaLocation in instance documents. Ming has action to upload the latest XML schema and validate it and the examples. o Issue 36 – Leave the description as is based on discussions with the apps-area review. o Issue 37 – Already removed (see -02 draft) per meeting at IETF-70.

Portable Symmetric Key Container (PSKC) and Symmetric Key Format (aka “ASN.1”): Alignment and work split between the two documents (Philip Hoyer, Sean Turner)  While the purpose of the ASN.1 format was to get credentials from one device to another, there was a discussion of how well-aligned the ASN.1 and PSKC are in terms of capabilities. The PSKC (-02 version) use cases were referenced, and only two discrepancies in capabilities with the ASN.1 document were found: o Use case, Section 3.1.2 “Bulk import of new credentials” and Section 3.1.3 “Bulk import of existing credentials” . PSKC can only support 1 set of attributes for all keys in the container . ASN.1 can support 1 set of attributes for all keys, and it can support 1 set of attributes per key . One change possible would be to add EncryptionMethod and DigestMethod to the PSKC KeyType. o Use case, Section 3.2.3, “Online update of an existing authentication token credential” . PSKC does not require a key to be included in the container; it can just transport key metadata. . ASN.1 requires a key to be included in the container. . Change ASN.1 to not require a key for support of DSKPP four-pass. . Note that this use case corresponds with DSKPP four-pass protocol. Change Section 3.2.3 to make it more generic and describe the case where the attributes (without the key) are carried in DSKPP (e.g., for four-pass).  Salah agreed to draft an explanation for the DSKPP document explaining the criteria by which one would use PSKC vs. ASN.1 formats.  Discussed three options for handling alignment of attribute names (decision was to make the attributes the same without requiring them to be convertible): o Attributes same for both ASN.1 and PSKC o Do nothing o Make sure they are convertible (e.g., PSKC to ASN.1, ASN.1 to PSKC)  Sean said that the next version of the ASN.1 draft will have new symmetric key attributes.  The biggest difference between attributes in PSKC and ASN.1 documents are those related to OTP tokens. . Open Issue Discussion regarding PSKC  To align PSKC document with rest of KEYPROV work, make use cases and terminology more generic. For example, avoid term “validation system”; replace “credential” to “key”.  Decision was to remove logo types from PSKC document

3  Note that the “Credential upload case”, Section 3.1.4, could be used to convey the key from the end host to the provisioning server. This should be clarified in the document.  Discussed each attribute in the schema: o Data . Hannes modified the schema as we discussed changes, and sent it to Ming as a proposal. o KeyAlgorithm . Reference D. Eastlake’s document (making sure that it includes OTP algorithms, including HOTP and SecurID, as well as those in Phillip Hallam-Bakers Algorithm URI I-D). . No need to list all algorithm id’s – focus only on Mandatory-to-Implement ones. Agreement reached that aes128-cbc is mandatory-to-implement. . Decision was that there is no a need to include OTP algorithms in the Mandatory-to-Implement list. Therefore, remove Section 5.1.2.1. o Usage . Change label for bullet 4 from “Sign” to “Integrity” . Change text to say, “the key will be used to generate a keyed message digest for data integrity or authentication purposes.” o Issuer . Change it from MANDATORY to OPTIONAL o Access Rules . Add a description regarding the extensibility of this attribute. . Add mention that if the recipient does not understand an Access Rule, then the recipient fails. o EncryptionMethod: . Agreement reached to only specify mandatory-to-implement algorithms, rather than everything. Reference a separate document (e.g., xmlenc). . Mandatory-to-implement algorithms are aes128 and pbes2. . Possible wording, “specify one for - asymmetric: http://www.w3.org/2001/04/xmlenc#rsa-1_5 - symmetric: http://www.w3.org/2001/04/xmlenc#aes128-cbc - passwd: "” o DigestMethod: . Change to “MAC” o OTP and CR specific Attributes . Relate to Usage Type. . Add a description of UsageType here to include:  OTP: ResponseFormat  CR: ChallengeFormat+ResponseFormat  Integrity: ResponseFormat  Encrypt: ResponseFormat  Unlock: - o AppProfileID . This parameter refers to the ID of the personalization profile of a smart card (esp. an EMV card) applet. The parameter came from work on a payment system, wherein the customer wants to use PSKC with EMV. . Refer to schema changes made by Hannes during the meeting as proposal for how to make this more general.

4 . Hannes’ changes suggest a way to combine AppProfileID, and to eliminate use of name-value pairs as they are not needed (nor expected) when using XML. (See for example attributes in “KeyType”).  Document requires restructuring so that it is more readable. Suggestion is for a more top-down approach. For example, move the entity-relationship diagram to the beginning of the document. Hannes will send a proposal for a restructured outline.  UserType, Section 6.1.5 o Discussed difficulty in trying to provide and maintain a complete list of attributes defining a user identity. Decision was to only rely on the UID, which could be a Distinguished Name or other form of identifier.  Discussed KeyContainerType, Section 6.1.6 o Decision was to rely on XMLEnc. This means that Section 6.1.7 (EncryptionMethodType) and Section 6.1.8 (DigestMethodType) should be removed). o Utilize Magnus’s proposal (note that RefList is optional) o Conformant profile to be defined with help from Magnus. Must make sure this profile is consistent with the Key Protection Profiles contained in the -02 version of DSKPP. o At least one keywrap profile that is FIPS 140-2 compliant is required. o Philip Hoyer to send a commonly used algorithm id used in HSMs.  PIN Policy o Agreed that the PIN is represented by the key. o Decision was to adopt Philip Hoyer’s proposal (refer to schema snippets presented at IETF-70). Philip will write a description of this for the document. o Philip to add support for “no PIN” policy. o Philip’s proposal will be added to next draft and presented at KEYPROV meeting in Philadelphia. o Regarding PIN Usage Modes, Andrea to review these and provide information on how the PIN is embedded.  Regarding Issue #25 (Shall we explicitly add an indication to the child element of the Data element to indicate whether an element is encrypted?) o Hannes to present options to the mailing list and to the Apps Area XML experts for review.  Closed all issues (refer to http://www.tschofenig.com/twiki/bin/viewfile/KeyProv/KeyprovInterim2008? rev=1;filename=DSKPP_PSKC_Issues_updated.xls ) and the Issue Tracker (http://www.tschofenig.com:8080/keyprov ) o Issue 15 – OTP algorithms are not listed in document; reference external doc (see notes on “KeyAlgorithm” attribute, above) o Issue 16 – Same resolution as Issue 15 o Issue 17 – XML extensibility mechanism has been decided already o Issue 19 – Not applicable any more since we are relying on XMLenc o Issue 24 – Not applicable any more since we are relying on XMLenc o Issue 28 – Rely on proposed text based on presentation at IETF70. o Issue 29 – Rely on proposed text based on presentation at IETF70.