Portable Symmetric Key Container (PSKC) Mingliang Pei Philip Hoyer Dec. 3, 2007 70-th IETF, Vancouver

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

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.

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 ds:KeyInfo as the type to define the wrapping key Use pkcs-5 xml schema for PBE parameters Use xenc:EncryptedDataType 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

Comparison: Encryption Key by Current Spec vs. Magnus’s Proposal <pskc:EncryptionMethod Algorithm= "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2"> <PBEEncryptionParam EncryptionAlgorithm= "http://www.w3.org/2001/04/xmlenc#kw-aes128-cbc"> <PBESalt>y6TzckeLRQw=</PBESalt> <PBEIterationCount>1024 </PBEIterationCount> </PBEEncryptionParam> <IV>c2FtcGxlaXY=</IV> </pskc:EncryptionMethod> <pskc:EncryptionKey> <pskc:DerivedKey Id="#Passphrase1"> <KeyDerivationMethod Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2"> <Parameters xsi:type="pkcs-5:PBKDF2ParameterType"> <Salt> <Specified>y6TzckeLRQw= </Specified> </Salt> <IterationCount>1024 </IterationCount> <KeyLength>16</KeyLength> <PRF/> </Parameters> </KeyDerivationMethod> <xenc:ReferenceList> <xenc:DataReference URI="#ED"/> </xenc:ReferenceList> </pskc:DerivedKey> </pskc:EncryptionKey>

Comparison: Wrapped Key by Current Spec vs. Magnus’s Proposal <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" KeyId="77654321870"> … <Data Name="SECRET"> <Value> JSPUyp3azOkqJENSsh6b2hdXz1WBYypzJxEr+ikQAa22M6V/BgZhRg== </Value> <ValueDigest> i8j+kpbfKQsSlwmJYS99lQ== </ValueDigest> </Data> </Key> <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" KeyId="77654321870"> … <Data Name="SECRET"> <EncryptedValue Id="ED"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/> <xenc:CipherData> <xenc:CipherValue> JSPUyp3azOkqJENSsh6b2hdXz1WBYypzJxEr+ikQAa22M6V/BgZhRg==</xenc:CipherValue> </xenc:CipherData> </EncryptedValue> </Data> </Key>

Pros and Cons Pros Cons 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

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

Proposal: PIN policy Introduce an element called PINPolicy Each key optionally has a PIN policy A PIN policy may contain a PINUsage <xs:complexType name="PINUsageModeType">   <xs:choice maxOccurs="unbounded">       <xs:element name="LOCAL"/>       <xs:element name="PREPEND"/>       <xs:element name="EMBED"/>   </xs:choice> </xs:complexType> Pseudo sample: <Key> … <PINPolicy PINRef=“PIN ID x”> <PINUsageMode>LOCAL</PINUsageMode> </PINPolicy> </Key>

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?

PIN Policy example <KeyContainer ….> <…> <Device>          <DeviceId>…</DeviceId>          <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"  KeyId="77654321871">           <Issuer>Credential Issuer</Issuer>        <Usage OTP="true">  <ResponseFormat Format="DECIMAL" Length="6"/>  </Usage>             <FriendlyName>MyFirstToken</FriendlyName>            <Data Name="SECRET"><Value> zOkqJENSsh6b2hdXz1WBK/oprbY=</Value></Data>            <Data Name="COUNTER"><Value>AAAAAAAAAAA=</Value></Data>            <Expiry>10/30/2012</Expiry>              <PINPolicy PINRef="77654321872">                 <PINUsageMode>PREPEND</PINUsageMode>            </PINPolicy>                  </Key>          <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#PIN"            KeyId="77654321872">           <Issuer>Credential Issuer</Issuer>             <Usage> <ResponseFormat Format="DECIMAL" Length="4"/> </Usage>            <FriendlyName>RandomInitialTokenPIN</FriendlyName>            <Data Name="SECRET"><Value>zOkqJENSsh6b2hdXz1WBK/oprbY=</Value></Data>        </Device>    </KeyContainer>

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?

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/xmlenc#kw-aes128 http://www.w3.org/2001/04/xmlenc#kw-aes256 http://www.w3.org/2001/04/xmlenc#kw-tripledes Asymmetric http://www.w3.org/2001/04/xmlenc#rsa-1_5 http://www.w3.org/2001/04/xmlenc#rsa-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?

Where do we find URIs for algorithms? Xmldsig-core http://www.w3.org/2000/09/xmldsig E.g., http://www.w3.org/2000/09/xmldsig#hmac-sha1 RFC4051 - More xmldsig URIs http://www.tools.ietf.org/html/rfc4051 E.g., http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 XMLEnc spec http://www.w3.org/TR/xmlenc-core/#sec-Algorithms E.g., http://www.w3.org/2001/04/xmlenc#aes128-cbc New RFC draft for MORE http://ietfreport.isoc.org/ids/draft-hallambaker-algorithm-identifiers-00.txt Shall we register new key algorithm URIs here? OTP algorithms Algorithms used in PKCS#5 PBE Should it list all algorithms or only new algorithm URIs?

Topic 4: Logo Type Currently, each key (by pskc:KeyType) can have a Logo element of LogoType LogoType Schema Defined along with v1.0 of PSKC Separate schema file from PSKC Own namespace urn:ietf:params:xml:ns:keyprov:logo:1.0 Defined as a XML version of the ASN.1 version for a Certificate [RFC3709] A key can have an issuer’s logo, multiple community logo, and others. <complexType name="LogoType"> <sequence> <element name="CommunityLogos" type="logo:LogoInfoType" minOccurs="0" maxO ccurs="unbounded"/> <element name="IssuerLogo" type="logo:LogoInfoType" minOccurs="0"/> <element name="OtherLogos" type="logo:LogoInfoType" minOccurs="0" maxOccur s="unbounded"/> </sequence> </complexType>

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 <complexType name="LogoImageInfoType"> <sequence> <element name="Size" type="integer" minOccurs="0"/> <element name="xSize" type="integer" minOccurs="0"/> <element name="ySize" type="integer" minOccurs="0"/> <element name="Resolution" type="logo:LogoImageResolutionType" minOccurs="0"/> </sequence> <attribute name="colored" type="boolean" default="true"/> <attribute name="lang" type="string" use="optional"/> </complexType>

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

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: <KeyContainer> <Device> <Key> DSKPP: KeyType is an element used to mean what kind of key to request. It plays the equivalent role of KeyAlgorithmType in PSKC. Usage: <ClientHello> <SupportedKeyTypes> Algorithm URIs </SupportedKeyTypes> <ServerHello> <KeyType> AlgorithmURI </KeyType>

Resolution Options Change PSKC KeyType to something like KeyDataType Change DSKPP KeyType to KeyAlgorithmType <ClientHello> <SupportedKeyAlgorithmTypes> Algorithm URIs </SupportedKeyAlgorithmTypes> <ServerHello> <KeyAlgorithmType> AlgorithmURI </KeyAlgorithmType> Matches the value used: KeyAlgorithmType <-> Algorithm URI Concern: KeyAlgorithmType isn’t 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 <KeyContainer> <Device> <KeyData>

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