Key Prov PSKC Specification Sean Turner 75 th

Key. Prov PSKC Specification Sean Turner 75 th IETF meeting, Stockholm Jul. 2009

Agenda Status update p Changes since v 2 p Comments received from 2 nd working group last call p Next steps p

Status Update p p Submitted new version -03 addressing most comments from 1 st WGLC Addressed comment on Mac. Method (explicitly carrying generated MAC key encrypted with transport key) Added most editorial comments received from 1 st WGLC, thanks especially to Andrea Doherty, Salah Macchani and Tim Moses Called 2 nd Working group last call for PSKC 27 th of June

Changes since v 2 p p p Addressed comment on Mac. Method (explicitly carrying generated MAC key encrypted with transport key) Checked and corrected all examples with proper generated values Described how IV is conveyed and described padding (PKCS 5) for non padded key protection algorithms Minor schema changes to further agree on naming and reduce repetition of closing element names (e. g. Key. Id -> Key. Id) Aligned introduction and explicit mentioning of used XML namespaces to DSKPP spec Use of new W 3 C Derived. Key element for PBE

MAC Method p For algorithms that do not have inbuilt integrity checks it is possible to carry a separate MAC key (under the Key. Container)

MAC Method - Description p p p p When algorithms without integrity checks are used, such as AES 128 - CBC, a keyed MAC value MUST be placed in the <Value. MAC> element of the <Data> element. In this case the MAC algorithm type MUST be set in the <MACMethod> element of the <Key. Container> element. The MAC key MUST be a randomly generated key by the sender, a pre-shared one between the receiver and the sender, or one set by an application protocol that uses Key. Container. It is recommended that a sender generates a random MAC key. When the sender generates such a random MAC key, the MAC key material MUST be encrypted with the same encryption key specified in <Encryption. Key> element of the key container. The encryption method and encrypted value MUST be set respectively in the <Encryption. Method> element and the <Cipher. Data> element of the <MACKey> element in the <MACMethod> element. The <MACKey. Reference> element of the <MACMethod> element MAY be used to indicate a pre-shared MAC key or a provisioning protocol derived MAC key. Implementations of PSKC MUST support HMAC-SHA 1 as the mandatory-to-implement MAC algorithm.

Schema Changes p p Removed redundant elemention in attributes (e. g. Key. Id -> Key. Id) Added Mac. Method

Comments received – since 2 nd WGLC p p p All MINOR! (Received comments from Andrea, Sean Turner and Tim Moses) Algorithm profile document has expired Unclear descriptions: n n p Alignment issue for PBE – n p p p Device. Binding User. Id when User. Id for Key is different than for Device Note that according to DSKPP (-07, section 5. 2. 2), for Passphrase. Based Key Wrap, "the <ds: Key. Name> option MUST be used and the key name MUST identify the passphrase that will be used by the server to generate the key wrapping key. The identifier and passphrase components of <ds: Key. Name> MUST be set to the Client ID and authentication code components of AD (same AD as contained in this message). " However, in S 6. 2 of this version of PSKC, <ds: Key. Name> is not mentioned. A mechanism for referencing the key required to decrypt or verify would be useful, even when the key is carried in the same container Mandatory isn't an RFC 2119 keyword. I think we need to change where ever 'mandatory' is to work in a MUST. Some editorial

Next steps Resubmit new version of Algorithm profile document p Address 2 nd WGLC editorial comments p Resubmit next rev p Another last call? Or? p