The Dynamic Symmetric Key Provisioning Protocol (DSKPP)

KEYPROV WG

IETF-71 Philadelphia

March 11, 2008

Andrea Doherty

2

Current Status Interim face-to-face meeting held in Bedford Feb 6-7, 2008

Liaison report from IEEE P1619.3 chair Matt Ball Discussed/resolved all open:

DSKPP issues PSKC issues SKPC (ASN.1) issues DSKPP/PSKC alignment issues PSKC/SKPC alignment issues

Draft-ietf-keyprov-dskpp-03 was submitted Feb 25, 2008 Document cleanup Addresses comments received on mailing list and at IETF-70, as well

as resolutions from interim meeting

3

Draft -03 Document Updates Editorial Changes

Introduction Terminology Use Cases User Authentication Security Considerations

Object Model Aligned entities with PSKC and SKPC (e.g., Key Container -> Key

Package) Message Flows

Made corrections Imitated message flows in IKEV2 (RFC4306)

4

Draft -03 Document Updates (cont’d) Protocol Variants

Removed one-pass variant Provided rationale for four-pass

HTTP Binding Incorporated comments from Thomas Roessler of W3C

Conformance Section Updated based on input from Interim meeting

Schema Changes ElementDefault now equals “qualified” instead of “unqualified” Removed references to schemaLocation Rely on URL rather than URN for algorithm URI

5

Open Issues(refer to Issue Tracker - http://www.shingou.info:8080/keyprov/index)

# Description

A Authentication Code Format

B Scope of MAC

C Open Questions from Review

D IANA Considerations

E Examples Depend on PSKC

6

Issue A – Authentication Code Format Draft -03 does not specify a format

For interoperability purposes, a format should be defined as mandatory-to-implement

Proposed Approach Authentication code MUST contain a client identifier and one-time

use password Authentication code MAY contain a checksum (CRC16 of ISO3309) Rely on TLV format with a length set to 1 byte

7

Issue B – Scope of MAC MAC does not cover all messages/payloads (Pasi Eronen)

This limits future extensibility Typically, in key exchange protocols, the first message does not have

a MAC, but once a key is agreed on, it is used to MAC all subsequent messages (e.g., Finished messages in TLS and AUTH payloads in IKEV2)

Originally the MAC was only intended for key confirmation (Magnus Nystrom) The most critical elements are currently included in the MAC The MAC fulfills the need for key confirmation Would be better if final MAC included all components sent and

received by the server. This way one could get integrity protection of other protocol elements even ouside of a tunnel, e.g., in EAP-POTP.

8

Issue C – Open Questions from Review Review comments (Roessler) that still have to be addressed:

Identify early on in the document which namespace prefixes are used in the XML schema and what they mean.

Be clearer about what parts of ds:KeyInfoType are being used for payloads and public keys (see Section 11.2.3 and 11.3.3).

It would contribute to the clarity of the Security Considerations if there was a clear discussion of the assumptions beforehand, and a consistent use of attacker models later on.

Possible weakening of keys if both device and server support multiple key types with mutually interchangeable key material. Consider using the negotiated algorithm value as input into the MAC derivation mechanism. DSKPP currently only protects the key material To address this, the MAC can be expanded as per Issue B

9

Issues D and E Issue D - IANA Considerations are incomplete (Tschofenig)

KEYPROV co-chair (Hannes Tschofenig) to ask IANA whether it would be possible for them to post KEYPROV URIs on their Web Site

Section will be completed for next update

Issue E – Examples Depend on PSKC Examples may have to be updated when PSKC changes

10

Next Steps Close remaining issues

Effort required is relatively simple

Revise and resubmit draft for WGLC

In addition: Add SOAP binding document (e.g., draft-doherty-

keyprov-ct-kip-ws-00) as a working group item?