KeyProv PSKC Specification

1
KeyProvPSKC Specification

• Mingliang Pei
• Authors P. Hoyer, M. Pei and S. Machani
• 73nd IETF meeting, Minneapolis, Nov. 2008

2
Agenda

• Status update
• Outstanding issues
• Next steps

3
Status Update Revisions since v5

• Reviewed by Pasi and others with extensive
  comments
• Major enhancements
• IANA section is largely refined to include ltKeygt
  entity profile for each registered algorithm.
  This increases clarity on interoperability
• Passphrase based encryption support clarification
• Various other cleanups
• Spelling
• Descriptions
• Single mandatory algorithm
• Some schema changes for clarity

4
Revision 1 Key Entity XML Profile

• Problem
• Interoperability
• Many elements and attributes are optional in
  order to support broad types of keys
• How can a Provider know what elements and
  attributes are required and how they should be
  set for a particular key algorithm?
• Solution
• Explicitly specify the information for each
  registered OTP algorithms in IANA section
• Specify required elements and attributes
• Specify supported value ranges
• Provide an example

5
Revision 1 Key Entity XML Profile Sample

• 8.4.4.1. HOTP
• Common Name HOTP
• Class OTP
• URI http//www.ietf.org/keyprov/pskchotp
• Algorithm Definition http//www.ietf.org/rfc/
  rfc4226.txt
• Profile of XML attributes and subelements of
  the ltKeygt entity
• For a ltKeygt of this algorithm, the ltUsagegt
  subelements MUST be present. The "OTP" attribute
  of the ltUsagegt MUST be set "true and it MUST be
  the only attribute set. The element
  ltResponseFormatgt of the ltUsagegt MUST be used to
  indicate the OTP length and the value format.
• For the ltDatagt elements of a ltKeygt of this
  algorithm, the following subelements MUST be
  present in either the ltKeygt element itself or an
  commonly shared ltKeyPropertiesgt element.
• Counter
• The following additional constraints apply
• - The value of the ltSecretgt element MUST
  contain key material with a lengthy of at least
  16 octets (128 bits) if it is present.
• - The ltResponseFormatgt element MUST have
  the 'Format' attribute set to "DECIMAL", and the
  'Length' attribute MUST be between 6 and 9.
• - The ltPINPolicygt element MAY be present
  but the ltFormatgt child element of the ltPINPolicygt
  element cannot be set to "Algorithmic".

6
Revision 1 Key Entity Example (HOTP)

• lt?xml version"1.0" encoding"UTF-8"?gt
• ltKeyContainer Version"1.0"
• xmlns"urnietfparamsxmlnskeyprovpskc1.0"gt
• ltDevicegt
• ltDeviceInfogt
• ltManufacturergtTokenVendorAcmelt/Manufac
  turergt
• ltSerialNogt987654321lt/SerialNogt
• lt/DeviceInfogt
• ltKey KeyAlgorithm"http//www.ietf.org/key
  prov/pskchotp"
• KeyId"987654321"gt
• ltIssuergtIssuerlt/Issuergt
• ltUsage OTP"true"gt
• ltResponseFormat Length"8"
  Format"DECIMAL"/gt
• lt/Usagegt
• ltDatagt
• ltSecretgt
• ltPlainValuegtMTIzNDU2Nzg5MDEyMzQ
  1Njc4OTAlt/PlainValuegt
• lt/Secretgt
• ltCountergt

7
Revision 2 PBE Support Clarification

• Revised description (section 6.1.2) to add
  information how PKCS5 key derivation and
  encryption scheme should be specified
• Updated schema
• pskcKeyDerivationMethod uses PKCS5 XML element
  definition for better schema check
• ltpkcs-5PBKDF2-paramsgt instead of the equivalent
• ltpkcs-5Parameters xsitype"pkcs-5PBKDF2Paramete
  rType"gt
• Define ltpskcEncryptionSchemegt to better specify
  PBES2
• ltxencEncryptionMethod Algorithm
• "http//www.rsasecurity.com/rsalabs/pkcs/schema
  s/
• pkcs-5pbes2"gt
• ltpskcEncryptionScheme Algorithm
• "http//www.w3.org/2001/04/xmlencaes128-cbc"
  gt
• lt/pskcEncryptionSchemegt
• lt/xencEncryptionMethodgt

8
Revision 3 Various Cleanups

• Only one mandatory encryption and hash algorithm
  to support
• Mandatory encryption algorithm
• http//www.w3.org/2001/04/xmlencaes128-cbc
• Mandatory hash algorithm
• http//www.w3.org/2000/09/xmldsighmac-sha1
• Optional camellia key encryption algorithms are
  included
• XML encryption clarification
• XML schema is used for raw key material
  encryption, not XML document encryption
• Some schema changes for better consistency and
  standards

9
Revision 3 Other Schema Changes

• ltUserIdgt of a ltKeygt MUST be DN
• Standard XML attribute ltxmlidgt is used
• In the last revision, the XML ID attribute is
  changed to use the standard XML type ltxsIDgt
  type. In this revision, we eliminate names at all
  by referring to ltxmlidgt
• ltxsattribute name"ID" type"xsID/gt to
• ltxsattribute ref"xmlid/gt
• Affected PSKC types
• DerivedKeyType
• KeyContainerType
• KeyPropertiesType

10
Outstanding Issues

• Security concerns over DeviceId using PAN
  (Primary Account Number)
• PAN is the credit card number. Passing the
  information in a KeyContainer requires
  participating entities to handle the data
  properly such as in compliance of PCI.
• Clarify how a different MAC from encryption key
  can be specified
• Current schema doesnt define a type to carry MAC
  key
• A separate MAC key could be same as the KEK,
  pre-loaded, derived, and created (similar to
  DSKPP MAC key generation)
• Register HOTP algorithms as URN without using
  http//www.ietf.org/xxx URI
• We preferred to register algorithms as URI for
  consistency
• http//www.ietf.org/keyprov/pskchotp
• http//www.w3.org/2001/04/xmldsig-morersa-sha256
• http//www.rsasecurity.com/rsalabs/otps/schemas/20
  05/09/otps-wstSecurID-AES
• Using www.ietf.org URI isnt permitted. URN
  should be used
• Shall we register HTOP as URN or find other URI
  prefix?
• urnietfparamsxmlnskeyprovpskchotp

11
Outstanding Issues

• Register additional OTP algorithms
• VASCO OTP algorithm, others (?)
• Random generating OTP algorithm (e.g. SMS OTP
  use)
• KeyContainer XML schema version as an attribute
  or as part of the namespace urn
• Version in root element considered best practice
  for minor changes (e.g. new attribute addition)
  instead of bumping up namespace urn version.
• Namespace version is changed when old schema
  wont validate in the new schema
• http//www.xfront.com/Versioning.pdf
• Having an integer type instead of two 32-bit and
  64-bit types (intDataType and longDataType)
• Revise for default value support
• When XML schema uses default values, signature
  may break
• Add a paragraph to indicate that the "signer"
  always fills in the right data, or make the
  attribute required
• Make examples in the Appendix as test vectors
  (Work in progress)

12
Next Steps

• Review feedbacks and address the issues into the
  next revision
• Target last call after the next revision