Subject: [KEYPROV] FW: New Version Notification for draft-ietf-keyprov-dskpp-10

From: <[email-masked]>
Date: Fri, 9 Apr 2010 22:08:40 -0400

fyi

________________________________

From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Fri 4/9/2010 10:08 PM
To: Doherty, Andrea
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: New Version Notification for draft-ietf-keyprov-dskpp-10 

A new version of I-D, draft-ietf-keyprov-dskpp-10.txt has been successfully submitted by Andrea Doherty and posted to the IETF repository.

Filename:        draft-ietf-keyprov-dskpp
Revision:        10
Title:           Dynamic Symmetric Key Provisioning Protocol (DSKPP)
Creation_date:   2010-04-08
WG ID:           keyprov
Number_of_pages: 95

Abstract:
DSKPP is a client-server protocol for initialization (and
configuration) of symmetric keys to locally and remotely accessible
cryptographic modules.  The protocol can be run with or without
private-key capabilities in the cryptographic modules, and with or
without an established public-key infrastructure.

Two variations of the protocol support multiple usage scenarios.
With the four-pass variant, keys are mutually generated by the
provisioning server and cryptographic module; provisioned keys are
not transferred over-the-wire or over-the-air.  The two-pass variant
enables secure and efficient download and installation of pre-
generated symmetric keys to a cryptographic module.

This document builds on information contained in [RFC4758], adding
specific enhancements in response to implementation experience and
liaison requests.

The IETF Secretariat.

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 13 Apr 2010 09:38:42 +0200

Hi Andrea,
I still don't see any connection between

   A.7.  Pre-Shared Manufacturing Key

      A cryptographic module is loaded onto a smart card after the card is
      issued to a user.  The symmetric key for the cryptographic module
      will then be provisioned using a secure channel mechanism present in
      many smart card platforms.  This allows a direct secure channel to be
      established between the smart card chip and the provisioning server.
      For example, the card commands (i.e., Application Protocol Data
      Units, or APDUs) are encrypted with a pre-issued card manufacturer's
      key and sent directly to the smart card chip, allowing secure post-
      issuance in-the-field provisioning.  This secure flow can pass
      Transport Layer Security (TLS) and other transport security
      boundaries.

      Note that two pre-conditions for this usage scenario are for the
      protocol to be tunneled and the provisioning server to know the
      correct pre-established manufacturer's key.

and DSKPP.  Who wrote this text BTW?

IMO, this is (approximately) what DSKPP *should* have supported in order
to offer the advantages needed for wide-scale adoption.

/anders

[email-masked] wrote:
> _______________________________________________
> KEYPROV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyprov
>

---

From: <[email-masked]>
Date: Tue, 13 Apr 2010 14:36:36 -0400

Anders,
This use case originated from OATH (see attached doc, Sec 1.2, Use Case
#7), and has been in the KEYPROV draft since version -01, albeit with
different wording due to editing process.  It is applicable to the
two-pass variant of DSKPP. Ming Pei and/or Philip Hoyer can provide you
with more details. 
Andrea

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]] 
Sent: Tuesday, April 13, 2010 3:39 AM
To: Doherty, Andrea
Cc: [email-masked]
Subject: Re: [KEYPROV] FW: New Version Notification for
draft-ietf-keyprov-dskpp-10

Hi Andrea,

      A cryptographic module is loaded onto a smart card after the card
is
      issued to a user.  The symmetric key for the cryptographic module
      will then be provisioned using a secure channel mechanism present
in
      many smart card platforms.  This allows a direct secure channel to
be
      established between the smart card chip and the provisioning
server.
      For example, the card commands (i.e., Application Protocol Data
      Units, or APDUs) are encrypted with a pre-issued card
manufacturer's
      key and sent directly to the smart card chip, allowing secure
post-
      issuance in-the-field provisioning.  This secure flow can pass
      Transport Layer Security (TLS) and other transport security
      boundaries.

/anders

[email-masked] wrote:
> A new version of I-D, draft-ietf-keyprov-dskpp-10.txt has been
successfully submitted by Andrea Doherty and posted to the IETF
repository.

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 13 Apr 2010 21:13:56 +0200

Thanx Andrea,

This section *is* actually dead wrong.
Cards do not process XML message they (typically) process APDUs.
Note: this is not a WGLC issue but I just wanted to highlight
an error in the margin :-)

A *working* implementation of A.7 is featured in my recent
"Cloud" Token design where an *untrusted proxy* facilitates
*end-to-end secured communication* between a card and issuer.
Sounds like a genuine oxymoron?  Well, the "trick" here is to
map APDUs into XML (1-2-1) and with the help of a persistent
session key, MACs, sequence counters, and selective encryption
of data create a scheme where any of the end-points will note if
the proxy haven't performed what it was supposed to do.

Anders