Portable Symmetric Key Container (PSKC)

1
Portable Symmetric Key Container (PSKC)

• Mingliang Pei
• Philip Hoyer
• Dec. 3, 2007
• 70-th IETF, Vancouver

2
Agenda

• Status update
• Main Discussion Topics
• Use of XMLEnc / XMLDsig
• PIN policy
• Profile of supported algorithms
• Logo Type
• List of Other Open Issues
• Next step

3
Status update - changes

• 11/5/2007 Version -01
• Changed algorithm enumerations to URIs
• Changed all attribute name initial from lower
  case to upper case
• Changed VersionType to use 2 major digits and 3
  minor digits.
• 11/18/2007 Version -02
• Changed PSKC schema file to not use default
  namespace
• Fixed examples and verified them against schema
• Added name TIME_DRIFT for HOTP time based
  algorithm
• Changed HOTP key algorithm URI from URN style to
  URL. This causes some inconsistency with DSKPP
  v1.1 and we will align both specifications in the
  next revision.
• Added description about Logo in the common
  attribute section.
• Added logo schema content in the schema section.
• Fixed a few typos.
• Updated acknowledgement section.

4
Topic 1 Use of xmlenc / xmldsig

• Main issue shall we leverage more XMLEnc for
  encryption key entry and encrypted value
  definition?
• Received various comments from Magnus and Andrea
  from RSA to increase use of xmlenc and xmldsig in
  PSKC spec
• Use dsKeyInfo as the type to define the wrapping
  key
• Use pkcs-5 xml schema for PBE parameters
• Use xencEncryptedDataType as the carrier of the
  wrapped keys
• No need for digest if key wrapping algorithms are
  used that preserve integrity
• The original design goal of PSKC is to keep it
  simple and small size without relying on
  extensive XMLEnc and XMLDsig schema

5
Comparison Encryption Key by Current Spec vs.
Magnuss Proposal

• ltpskcEncryptionMethod Algorithm
• "http//www.rsasecurity.com/rsalabs/pkcs/schemas/p
  kcs-5pbes2"gt
• ltPBEEncryptionParam EncryptionAlgorithm
• "http//www.w3.org/2001/04/xmlenckw-aes128-cbc"gt
  ltPBESaltgty6TzckeLRQwlt/PBESaltgt
• ltPBEIterationCountgt1024
• lt/PBEIterationCountgt
• lt/PBEEncryptionParamgt
• ltIVgtc2FtcGxlaXYlt/IVgt
• lt/pskcEncryptionMethodgt

• ltpskcEncryptionKeygt
• ltpskcDerivedKey Id"Passphrase1"gt
• ltKeyDerivationMethod
  Algorithm"http//www.rsasecurity.com/rsalabs/pkcs
  /schemas/pkcs-5pbkdf2"gt
• ltParameters xsitype"pkcs-5PBKDF2Parameter
  Type"gt
• ltSaltgt
• ltSpecifiedgty6TzckeLRQw
• lt/Specifiedgt
• lt/Saltgt
• ltIterationCountgt1024
• lt/IterationCountgt
• ltKeyLengthgt16lt/KeyLengthgt
• ltPRF/gt
• lt/Parametersgt
• lt/KeyDerivationMethodgt
• ltxencReferenceListgt
• ltxencDataReference URI"ED"/gt
• lt/xencReferenceListgt
• lt/pskcDerivedKeygt
• lt/pskcEncryptionKeygt

6
Comparison Wrapped Key by Current Spec vs.
Magnuss Proposal

• ltKey KeyAlgorithm"http//www.ietf.org/keyprov/psk
  chotp"
• KeyId"77654321870"gt
• ltData Name"SECRET"gt
• ltValuegt JSPUyp3azOkqJENSsh6b
  2hdXz1WBYypzJxErikQAa22M6V/BgZhRg
• lt/Valuegt
• ltValueDigestgt i8jkpbfKQsSlwmJYS99lQ
• lt/ValueDigestgt
• lt/Datagt
• lt/Keygt

• ltKey KeyAlgorithm"http//www.ietf.org/keyprov/psk
  chotp"
• KeyId"77654321870"gt
• ltData Name"SECRET"gt
• ltEncryptedValue Id"ED"gt
• ltxencEncryptionMethod
  Algorithm"http//www.w3.org/2001/04/xmlenckw-aes
  128"/gt
• ltxencCipherDatagt
• ltxencCipherValuegt
• JSPUyp3azOkqJENSsh6b2hdXz1WBYypzJxErikQAa22M6V/Bg
  ZhRglt/xencCipherValuegt
• lt/xencCipherDatagt
• lt/EncryptedValuegt
• lt/Datagt
• lt/Keygt

7
Pros and Cons

• Pros
• More standard
• Can ride on extension to xmlenc and xmldsig spec
• Possible advantage of using existing tools

• Cons
• More complex for bulk (need to create xmlenc
  refs)
• Increased scope for interoperability with XMLENC
  spec
• More schemas to import
• Larger payload size
• Major re-work late in spec lifecycle

8
Topic 2 PIN policy

• Issue how to transmit initial PIN value for
  devices using PSKC
• Current spec only specifies whether a PIN is used
• Lack of specification how PIN is transferred and
  its usage
• Use Case Considerations
• Allow possibly multiple PINs and which keys are
  protected by the PIN.
• A PIN can be used in multiple ways
• Locally authenticated in a client
• Part of data sent to server for validation along
  with that from a target key
• Embedded in device

9
Proposal PIN policy

• Introduce an element called PINPolicy
• Each key optionally has a PIN policy
• A PIN policy may contain a PINUsage

• ltxscomplexType name"PINUsageModeType"gt
•   ltxschoice maxOccurs"unbounded"gt
•       ltxselement name"LOCAL"/gt
•       ltxselement name"PREPEND"/gt
•       ltxselement name"EMBED"/gt
•   lt/xschoicegt
• lt/xscomplexTypegt
• Pseudo sample
• ltKeygt
• ltPINPolicy PINRefPIN ID xgt
• ltPINUsageModegtLOCALlt/PINUsageModegt
• lt/PINPolicygt
• lt/Keygt

10
Proposal PIN transmit

• Leverage Key element to carry PIN value by
  treating PIN as one kind of credential
• Can re-use all wrapping and usage parts for PIN
  value definition
• Use a reference ID attribute to associate a Key
  and a PIN that protects it
• PINPolicy of a key has an attribute referring to
  PIN entry
• PIN entry has an attribute referring to key ID
  that it protects
• Questions
• Do we need to allow a device level PIN policy?
• Any other use cases with regard to PIN usage?

11
PIN Policy example

•    ltKeyContainer .gt
• ltgt
•        ltDevicegt
•          ltDeviceIdgtlt/DeviceIdgt
•          ltKey KeyAlgorithm"http//www.ietf.org/ke
  yprov/pskchotp"  KeyId"77654321871"gt
•           ltIssuergtCredential Issuerlt/Issuergt
•        ltUsage OTP"true"gt  ltResponseFormat
  Format"DECIMAL" Length"6"/gt  lt/Usagegt
•             ltFriendlyNamegtMyFirstTokenlt/Friendl
  yNamegt
•            ltData Name"SECRET"gtltValuegt
  zOkqJENSsh6b2hdXz1WBK/oprbYlt/Valuegtlt/Datagt
•            ltData Name"COUNTER"gtltValuegtAAAAAAA
  AAAAlt/Valuegtlt/Datagt
•            ltExpirygt10/30/2012lt/Expirygt
•              ltPINPolicy PINRef"77654321872"gt
•                 ltPINUsageModegtPREPENDlt/PINUsag
  eModegt
•            lt/PINPolicygt        
•          lt/Keygt
•          ltKey KeyAlgorithm"http//www.ietf.org/ke
  yprov/pskcPIN"
•            KeyId"77654321872"gt
•           ltIssuergtCredential Issuerlt/Issuergt
•             ltUsagegt ltResponseFormat
  Format"DECIMAL" Length"4"/gt lt/Usagegt

12
Questions

• Do we need to allow a device level PIN policy for
  bulk case?
• For local device PIN, PIN policy applies to the
  key device and one shared PIN policy should be
  sufficient
• Any other use cases with regard to PIN usage?

13
Topic 3 Profiling of PSKC

• With the move to URIs as algorithm identifiers
  from an enumerated list we need to define
• A list of algorithms that an implementation MUST
  support
• PBE
• PKCS5
• Symmetric
• http//www.w3.org/2001/04/xmlenckw-aes128
• http//www.w3.org/2001/04/xmlenckw-aes256
• http//www.w3.org/2001/04/xmlenckw-tripledes
• Asymmetric
• http//www.w3.org/2001/04/xmlencrsa-1_5
• http//www.w3.org/2001/04/xmlencrsa-oaep-mgf1p
• A list of algorithms it SHOULD support
• ?
• Do we need more than one profile?
• Do we need to have a symmetric and asymmetric
  profile?
• Where do we define additional URIs not defined
  yet?

14
Where do we find URIs for algorithms?

• Xmldsig-core
• http//www.w3.org/2000/09/xmldsig
• E.g., http//www.w3.org/2000/09/xmldsighmac-sha1
• RFC4051 - More xmldsig URIs
• http//www.tools.ietf.org/html/rfc4051
• E.g., http//www.w3.org/2001/04/xmldsig-morehmac-
  sha256
• XMLEnc spec
• http//www.w3.org/TR/xmlenc-core/sec-Algorithms
• E.g., http//www.w3.org/2001/04/xmlencaes128-cbc
• New RFC draft for additional algorithms
• http//ietfreport.isoc.org/ids/draft-hallambaker-a
  lgorithm-identifiers-00.txt
• How shall we register new key algorithm URIs?
• OTP algorithms
• Algorithms used in PKCS5 PBE
• In this draft? In KEYPROV drafts? Other?
• Should it list all algorithms or only new
  algorithm URIs?

15
Topic 4 Logo Type

• Currently, each key (by pskcKeyType) can have a
  Logo element of LogoType
• LogoType Schema
• Defined along with v1.0 of PSKC
• Separate schema file from PSKC
• Own namespace urnietfparamsxmlnskeyprovlogo
  1.0
• Defined as a XML version of the ASN.1 version for
  a Certificate RFC3709
• A key can have an issuers logo, multiple
  community logo, and others.
• ltcomplexType name"LogoType"gt
• ltsequencegt
• ltelement name"CommunityLogos"
  type"logoLogoInfoType" minOccurs"0" maxO
• ccurs"unbounded"/gt
• ltelement name"IssuerLogo"
  type"logoLogoInfoType" minOccurs"0"/gt
• ltelement name"OtherLogos"
  type"logoLogoInfoType" minOccurs"0" maxOccur
• s"unbounded"/gt
• lt/sequencegt
• lt/complexTypegt

16
Logo Type Issues

• Where do we document LogoType if not in PSKC
  spec?
• Intended to be a common type similar to algorithm
  URIs such that LogoType can be used by other
  specifications
• Options
• Propose a new RFC draft about Logo for keys
• RFC 3709 - Internet X.509 Public Key
  Infrastructure Logotypes in X.509 Certificates
• Make it common schema as it is today and explain
  LogoType and schema information in PSKC spec
• Is it sufficient to define logo type to include
  only image data and MIME type?
• Currently additional logo image parameters such
  as size and resolution are allowed, as defined
  from the original certificate logo type
  definition
• ltcomplexType name"LogoImageInfoType"gt
• ltsequencegt
• ltelement name"Size" type"integer"
  minOccurs"0"/gt
• ltelement name"xSize" type"integer"
  minOccurs"0"/gt
• ltelement name"ySize" type"integer"
  minOccurs"0"/gt
• ltelement name"Resolution"
  type"logoLogoImageResolutionType"
  minOccurs"0"/gt
• lt/sequencegt
• ltattribute name"colored" type"boolean"
  default"true"/gt
• ltattribute name"lang" type"string"
  use"optional"/gt
• lt/complexTypegt

17
Open Issues

• OTP algorithm URI definition location
• Proposed in v1.2
• HOTP URI specified in PSKC
• Vendor patented / specific algorithm is up to the
  owner to provide URI, e.g. SecurID, VASCO time
  based, ActivIdentity time / event based etc.
• ValueDigest with Keyed digest (HMAC) vs. unkeyed
  (SHA1)
• Concerns
• Keyed digest needs verification of digest key
  itself
• What digest key to use when a certificate is used
  for encryption? Public key is used in this case.
• Is regular digest over raw secret safe? Keyed
  digest is used for better security.
• URI for PSKC KeyContainer
• Needed by DSKPP to indicate preference of
  requested key container format
• Propose to define it in DSKPP, not in PSKC

18
Alignment between DSKPP and PSKC

• Majority of them have been resolved
• KeyType / KeyAlgorithmType
• PSKC KeyType is a type used to define what a key
  is. One of its attribute KeyAlgorithmType
  indicates the type of the key. Usage
• ltKeyContainergt
• ltDevicegt
• ltKeygt
• DSKPP KeyType is an element used to mean what
  kind of key to request. It plays the equivalent
  role of KeyAlgorithmType in PSKC. Usage
• ltClientHellogt
• ltSupportedKeyTypesgt Algorithm URIs
  lt/SupportedKeyTypesgt
• ltServerHellogt
• ltKeyTypegt AlgorithmURI lt/KeyTypegt

19
Resolution Options

• Change DSKPP KeyType to KeyAlgorithmType
• ltClientHellogt
• ltSupportedKeyAlgorithmTypesgt Algorithm URIs
  lt/SupportedKeyAlgorithmTypesgt
• ltServerHellogt
• ltKeyAlgorithmTypegt AlgorithmURI
  lt/KeyAlgorithmTypegt
• Matches the value used KeyAlgorithmType lt-gt
  Algorithm URI
• Concern KeyAlgorithmType isnt as popular as
  KeyType by Google search to mean type of key to
  use.
• Change PSKC KeyType to something like KeyDataType
• Concern not as clean as KeyType for the object
  model Container, Device and Key
• ltKeyContainergt
• ltDevicegt
• ltKeyDatagt

20
Next Steps

• Resolve outstanding issues using the mailing list
  and conf calls
• Revise and resubmit draft for review