Keyprov PSKC spec

1. Keyprov PSKC spec Philip Hoyer 71-st IETF, Philadelphia

2. Agenda • Status update • Discussion points • Key Attribute – transmission and extension • Current approach • SAML attribute assertion schema • Current spec example • Comparison between current and new proposal • Mailing list extension discussion   • List of outstanding issues

3. Status update – changes based on draft -03 from 22/2/2008 • Completely reworked spec based on an entity description top-down approach • Aligned terminology (credential->key) • Removed LogoType • Adopted xml encryption types within schema • Added PINPolicy to allow transmission of PINs • Added start and expiry date to device and key entity • Removed UserEntity • Device -> user binding is via a UserId attribute in device • Added examples for PIN transmission and asymmetric wrapping • More detailed section on protection methods of payload • Added profile of symmetric, password based, key wrapping and asymmetric algorithms referenced also from DSKPP • Explicit section on attribute semantics that can be referenced from ASN.1 spec

4. Discussion: how to transmit key attribute values • Lots of traffic on mailing list • Main points: • Need a way to carry “attributes” related to a key • An attribute is not an XML attribute but key related meta-data • Key Attribute model based on name-values is common practice in existing crypto APIs such as PKCS#11 • An attribute can be encrypted or plaintext • Spec needs to be able to cater for a list of attributes • Not all attributes are semantically defined • Need to be able to cater for future attributes • Issue got confused between extension of XML elements and attributes and ability to carry a list of not pre-defined key metadata

5. Current approach to transmit key attributes • Attributes are a list of name value pairs: <xs:complexType name="DataType"> <xs:sequence> <xs:choice> <xs:element name="PlainValue" type="xs:base64Binary"/> <xs:element name="EncryptedValue" type="xenc:EncryptedDataType"/> </xs:choice> <xs:element name="ValueMAC" type="xs:base64Binary" minOccurs="0"/> </xs:sequence> <xs:attribute name="Name" type="xs:string" use="required"/> </xs:complexType> • Spec defines semantics for reserved attributes eg: COUNTER: the event counter for event based OTP algorithms. 8 bytes unsigned integer in big endian (i.e. network byte order) form base64 encoded

6. SAML Attribute assertion schema <element name="AttributeStatement" type="saml:AttributeStatementType"/> <complexType name="AttributeStatementType"> <complexContent> <extension base="saml:StatementAbstractType"> <choice maxOccurs="unbounded"> <element ref="saml:Attribute"/> <element ref="saml:EncryptedAttribute"/> </choice> </extension> </complexContent> </complexType> <element name="Attribute" type="saml:AttributeType"/> <complexType name="AttributeType"> <sequence> <element ref="saml:AttributeValue" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="Name" type="string" use="required"/> <attribute name="NameFormat" type="anyURI" use="optional"/> <attribute name="FriendlyName" type="string" use="optional"/> <anyAttribute namespace="##other" processContents="lax"/> </complexType> <element name="AttributeValue" type="anyType" nillable="true"/> <element name="EncryptedAttribute" type="saml:EncryptedElementType"/>

7. Current spec attribute example <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" KeyId="0755225266"> <Issuer>AnIssuer</Issuer> <Usage OTP="true"> <ResponseFormat Length="6" Format="DECIMAL"/> </Usage> <Data Name="COUNTER"> <PlainValue>AprkuA==</PlainValue> </Data> <Data Name="SECRET"> <EncryptedValue> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> <xenc:CipherData> <xenc:CipherValue> kyzrWTJuhJKQHhZtf2CWbKC5H3LdfAPvKzHHQ8SdxyE= </xenc:CipherValue> </xenc:CipherData> </EncryptedValue> <ValueMAC>cwJI898rRpGBytTqCAsegaQqPZA=</ValueMAC> </Data> <ExpiryDate>2012-12-31T00:00:00</ExpiryDate> </Key>

8. <Key….> <Data Name="SECRET"> <EncryptedValue> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> <xenc:CipherData> <xenc:CipherValue> kyzrWTJuhJKQHhZtf2CWbKC5H3LdfAPvKzHHQ8SdxyE= </xenc:CipherValue> </xenc:CipherData> </EncryptedValue> <ValueMAC>cwJI898rRpGBytTqCAsegaQqPZA=</ValueMAC> </Data> <Data Name="COUNTER"> <PlainValue>1234</PlainValue> </Data> </Key> <Key ....> <Secret> <EncryptedValue> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/> <xenc:CipherData> <xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=</xenc:CipherValue> </xenc:CipherData> </EncryptedValue> </Secret> <Counter> <PlainValue>1234</PlainValue> </Counter> </Key> Comparison between current spec Hannes proposal on mailing list

9. Pros Schema is always valid does not need to change for new attributes Way to transmit attributes in line with ASN.1 spec Familiar to crypto programmers (pkcs#11) Cons Not very XML Pros More XML style Allows for better typing of plainvalues Cons Harder to parse Schema needs extension with every new attribute type pros and consCurrent Hannes

10. Mailing list extension discussion • Chair Phillip Hallam-Baker with Tony Nadalin (IBM) • On structured data, distinguish between extending the protocol schema and incorporating lists of tag value pairs: • Using <any> to extend the protocol is bad, you lose the ability to perform schema validation on the protocol elements. • Using <any> for structured tag-value pairs is acceptable and is the prefered method if you have a tag-value pair that you may need to instantiate into multiple schemas. • So for example, if X.509 was an XML data format: • Changes to the X.509v3 cert format should use inheritance/subclassing so that the cert can be schema validated. • <any> should be used at the point where X.509v3 requires an OID-Structure pair defining a certificate extension. This allows an extension to be incorporated in Certificates, CRLs, OCSP, etc. • Comment from Anders Rundgren (RSA) • A remaining issue is that there is no way figuring out which extensions are understood and supported except by requesting vendor support. • X.509 world has a concept known as "non-critical" extensions. On the surface this looks like a great idea (just skip things you don't understand), but the reality is that if you don't support a bunch of these you cannot for example know if a certificate is revoked or not. • Issue - how do we register new key metadata semantics • informal RFC? • New version of PSKC with specific section about semantics?

11. Outstanding Issues • Fix a few TODOs: • Extend definition of userId for user device binding, current proposal is DN style (OU=Engineering, CN=James…) • Add definition of type in DerivedKey • Add example of asymmetric key protection in section 6.2 • Should plaintext be string instead of base64 • Clean up references to OTP algorithm URI in Section 6.3.1.2 • Reference Eastlake informational RFC • Specify some locally (RSA SecurID, ActivIdentity,others)? • change URI xxx/pskc#valuecompare to xxx/pskc#pin in section 6.3. #valuecompare is not a good name for type of credential (PIN). • Clean up reference section (some reference may not be "Normative" such as OATHRefArch ) • More clarification of ValueMac for specific transport security options (eg asymmetric, kw- algos not all HSMs) • Make sure all examples use ‘real key and hash values’ • add support of a key template to spec (alignment w/ASN.1 spec)?