Symmetric Key Provisioning – KEYPROV WG Chair(s): Phillip Hallam-Baker Hannes Tschofenig Security Area Director(s): Russ Housley Sam Hartman Meeting Minute Taker: Steffen Fries Charter http://www.ietf.org/html.charters/keyprov-charter.html 22.03.2007 0 Blue sheets & Plea for minute taker * First WG meeting 1 Agenda Bash * Some developments on proposal side, but not dramatically * Andrea Dohorty: advertises presentation for convergence --> after protocol discussion 2 Update on current WG status (5 mins) * 4 input documents, no further in progress * Problems with mailing list, will move to IETF server * Meeting after plenary today to further plan work 3 IEEE 1619.3 status PHB (5 mins) * Standards group, subcommittee for security for storage systems * Certain overlap with this group * Phil participated in one of the meetings, mainly product discussion * No traffic from IEEE to keyprov expected, but the other way around may work * EKMI --> other WG with a similar topic * Paul Hoffman: Intention to form a liaison with IEEE --> will be decided, when protocol proposal is available 4 Protocol draft-doherty-keyprov-ct-kip-ws-00.txt This document defines a SOAP-based Web Service interface intended for use by implementor's of the Cryptographic Token Key Initialization Protocol (CT-KIP) to support four-pass (i.e., two round-trip) cryptographic token key initialization. Reader familiarity with CT- KIP is required. * Goal: o define SOAP based protocol on web service layer for use with CT-KIP o Driven from implementations o Provisioning service should be able to run in highly available and distributed environment o Maintain security assurance level * Implementations have been emerged --> SW toolkits * Inline token provision --> initialization and configuration * Interest grows in CT-KIP, so there is need for standardized interface * Usage: o User enrolls for token (via CT provisioning application) o User triggers initialization and configuration of token through CT PA o CT binds key material to token * CT-KIP-WS deployment options * Discussion: o Paul Hoffman: CT-KIP is stateful, WS is stateless, disconnection? Author: WS is not changed o Pasi: Phones do not talk https? Author: may use TLS o Chair keys should be wrapped instead of transport layer security o ?? if WS is there, use WS security --> author: not used, but may be used in the draft; phil: might make sense in certain scenarios (route a message in networks environment with multiple layers of XML firewalls)--> discussion needs to be done (open issue) o Hannes: not al in one document, small drafts preferred * CT-KIP-WS trigger --> CT-KIP allows for an optional trigger message * CT-KIP-WS Parameters o Auth data: user authentication (e.g., user with activation code) o Provisioning data (device ID, type) * Operations (example given for 4 pass) o Server sends nonce, which is recently the client allowing stateless operation o Discussion * Paul Hoffman: TCP is modeled here by using the nonce? WS feature statelessness is circumvented by this trick; * Phil: idea in WS (SOAP) messages have header and body, each message atomic and stateless, messages compiled in protocols, much more flexible than http; here one could have more than one protocol flow; layer above WSTL (orchestration --> not seen a document) * ?? in practice people use cookies * No violation of statelessness * Open issues o AuthData and ProvisioningData are opaque (intentional, to enable application to define these) o Both are mandatory fields o CT-KIP request and response PDUs are base64 encoded blobs, question if this is to be continued o Version information missing * Next steps o Broader review needed o Converge it or keep it as stand alone draft-nystrom-keyprov-ct-kip-two-pass-00 This document describes extensions to the Cryptographic Token Key Initialization Protocol (CT-KIP) to support one-pass (i.e. one message) and two-pass (i.e. one round-trip) cryptographic token key initialization. * Short update, not much changes since BoF * Initializing and configuring cryptographic token on the fly * RFC4758: 4 pass protocol, very stable, being run life with customers * 3rd draft of CT-KIP extensions for 1 and 2 pass * Comparison of approaches in slides o 1 pass: only pushing key to client o 2 pass … o 4 pass … * Network latency as one reason for coming up with extension * Pasi: 1 pass useful in network with out bidirectional network connectivity, but what is 2 pass good for assumed that this is done maybe once a year--> author agrees * Use cases for 2 pass? * Draft defines profiles for all pass variants: o 1 pass: telco operator wants to deploy keys to phones. Phones have known ID, telco provider pushes keys depending on the ID; not the first choice, only when other variants do not work * Crypto properties: o Key confirmation, replay protection, server authentication, MITM protection, user authentication, device authentication * Bindigs o SOAP o HTTP o Security * Next steps: o Broader review needed o Convergence proposal to be discussed later on, DSKPP * Discussion o Usable for key provisioning using for instance email, when SOAP is not available --> not clear if applicable, author will think about o ??? emphasizing SOAP based approach --> some advice * Hannes: not so far in WG to decide it yet, maybe in the future * Phil: has heard it before as soon as there is a application layer attempt in a WG draft-pei-keyprov-dynamic-symkey-prov-protocol-00.txt This document specifies a symmetric key provisioning protocol that supports provisioning of symmetric keys (One Time Password (OTP) keys or symmetric cryptographic keys) and associated attributes dynamically to already issued different types of strong authentication devices. This work is a joint effort by the members of OATH (Initiative for Open AuTHentication) to specify a protocol that can be freely distributed to the technical community. The authors believe that a common and shared specification will facilitate adoption of two- factor authentication on the Internet by enabling interoperability between commercial and open-source implementations. * DSKPP * Joint effort with OATH community * Protocol to dynamically issue a symmetric key to a device * Explicitly uses PSKC as default key container (portable symmetric key container) * Supports WS * Protocol overview o Xml based, SOAP/HTTP binding allowed o One request and response via secure channel o Two round trips for non-secure channel * Protocol features o Client authentication (e.g., shared secret, or acquire server nonce to send auth data) o Server authentication (e.g., certificate) o Several client capabilities, may be sent in request o PSKC-Credential container in server response o Encryption key for credential data o Extension fields * PSKC Introduction(Mingliang Pai) o Joint contribution with OATH o Common format to export keys o Use cases: * Offline, like credential migration by end-user, bulk import of credentials * Online, like provisioning a credential to end-user’s authentication token, server-to-server provisioning o Key Features * Support devices with limited crypto caps * XML based * Support of different key types, parameters, protection of secrets in container o Discussion * Chair encouraged all to read the documents, especially for product developers if they can * Paul Hoffman: Client needs XML parser? --> yes, but seems heavyweight; difference in producing XML and parsing XML * Phil: validation is the critical operation * Hannes: validation often not done * Pasi: XML schema seams to be to simple, extension, e.g., adding of algorithms currently not possible, Ming: will be updated * Hannes: parsing XML necessary to work with the protocols * ?? Requirements draft questioned, Phil: not in charter, may be added * Hannes: needs to be a separate document * Tim Polk: WG chartered with strong requirements as background, not acceptable to step backwards and do a requirements document, should be hashed out in the documents * Hannes: some solution proposals also contain requirements * Paul: is weary of us assuming that simple XML works here * Phil: certain low level XML problems * Hannes: validation not done, parsing needs to be done to be able to handle the protocol * Phil: make XML tutorial instead of security tutorial * Convergence CT-KIP and DSKPP (A.Doherty, Mingliang Pai) o Goal: * have just one protocol, * leverage existing one * Extend protocol as necessary o Early agreement will foster IEEE acceptance o Way forward: Adopt majority of CT content, add some DSKPP features o Necessary enhancements: * Better handling of software tokens on mobile phones * Support for different kind of keys (e.g., for Kerberos) o Gap Analysis * CT-KP (not in DSKPP) * supports mutually generates secrets by both sides * Token initialization * Full crypto suite negotiation * DSKPP (not in CT-KIP) * Supports multiple credential container formats * User authentication prior to provisioning * Explicit device authentication using certs o Merge options: * Payload format options * Explicitly declare payload format and parameters * Extend alg and cap negotiation * Rely on existing CT-KIP protocol extension * User authentication options * Explicitly declare AuthenticationDataType * Rely on existing CT-KIP protocol extension * Explicit device authentication * Explicitly declare AuthenticationDataType * Rely on existing CT-KIP protocol extension o Bindings * SOAP * HTTP * DSKPP has no header defined * Security o Open issues * Guiding principle for strongly typing request and response parameter * Keep core protocol simple and flexible, allowing prgs to define own extensions * Guiding principle for HTTP and WS binding * Consider whether name styling of message types o Discussion * Hannes: happy to converge the drafts, merge options do not seem to be critical, asking room for sense of the room if direction is right * Pasi: plans about combining the symmetric key container DSKPP and CT-KIP have both definitions and both have good think which should be kept * Andrea: maybe multiple container types will be supported * Pasi: unclear why , when both fulfill the same purpose * Andrea agrees * Tim Polk: strongly encourage to merge functional equivalent container into one, given the fact that the protocols are merged as well * Sean Turner: should be tightly coupled to WS stuff (state in document what you do and what WS does) * Tim: rely on multiple things already available * Phil: splitting out bindings in separate documents * Pasi: aggress with Paul, having bindings in separate documents, but HTTP special type of binding, quite different to SOAP binding * Straw poll: heading forward with merging: 13 people (app. 1/3 of the room) in favor * Note will be sent to the list for scheduling phone conferences regarding discussions for the merger * Pasi: discussions on the mailing list requested first * Hannes: work shall be done soon * Tim: settle only difficult things per phone conference, the rest on the list * Proposal to have bi-weekly telcos * Some further discussion about proposal to do jabber/telco/mailing list 5 Key Format draft-hoyer-keyprov-portable-symmetric-key-container-00.txt This document specifies a shared secret token format for transport and provisioning of shared secrets (One Time Password (OTP) keys or symmetric cryptographic keys) to different types of strong authentication devices. The standard token format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. 6 Next Steps (current drafts can be found at http://tools.ietf.org/wg/keyprov/)