1 / 20

Portable Symmetric Key Container (PSKC)

Portable Symmetric Key Container (PSKC). Mingliang Pei Philip Hoyer Dec. 3, 2007 70-th IETF, Vancouver. 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.

kali
Télécharger la présentation

Portable Symmetric Key Container (PSKC)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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

  5. <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: Encryption Key by Current Spec vs. Magnus’s Proposal

  6. <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> Comparison: Wrapped Key by Current Spec vs. Magnus’s Proposal

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

  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. 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 policy

  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    <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>          </Key>        </Device>    </KeyContainer>

  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/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?

  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/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 additional algorithms • http://ietfreport.isoc.org/ids/draft-hallambaker-algorithm-identifiers-00.txt • How shall we register new key algorithm URIs? • OTP algorithms • Algorithms used in PKCS#5 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 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>

  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 <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>

  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: <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>

  19. Resolution Options • 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>

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

More Related