Provisioning of Symmetric Keys WG 
=================================

TUESDAY, March 24, 2009
1520-1700 Afternoon Session II
Room: Franciscan A

Meeting Agenda Available at: http://www3.ietf.org/proceedings/09mar/slides/keyprov-0.ppt

Sean Turner is taking notes.  Sam Ashmore is taking jabber notes.  Thanks to both.
The Jabber notes can be found here: http://jabber.ietf.org/logs/keyprov/2009-03-24.txt

Ming presented his slides PKSC slides available at: http://www3.ietf.org/proceedings/09mar/slides/keyprov-1.ppt.

Document significantly reorganized: flow, removed algorithm section, aligned with SKSML OASIS/NIST SP800-57.  Issued WGLC and the changes include:
 - removed key properties because bulk provisioning is more important
 - grouped elements for keys with that key
 - aligned with KeyPolicy
 - removed mandatory key wrap algorithm instead suggested 3 because aes key wrap required 64-bit keys and PSKC supports any size keys

Comments received:
Slide 6: a major issue (because it's bad cryptography) to use the same MAC key is the same as the key encryption key. Chocies are: 1) derive key 2) create a separate random MAC 3) pre-defined key.  

David Black's comment: Use option 2. Predefined in bad.

Hannes: Didn't somebody else already do this.

David Black: IPsec and TLS generate a master ke and you generate the KEK and MAC key from the master

Hannes: Was thinking about W3C.

Ming: W3C isn't worried about privacy but we need it.

Hannes: Go for option 2, but will check with W3C guys.

Slide 7: 
- Example AES encryption example is wrong
- Need clearer definition for DeviceInfo.DeviceBinding (Andrea to provide text)
- Many nits
- Terminology alignment (Andrea's got some slides)

Next steps:
 - Fix MAC, do edits, resubmit, and WG LC
 - Assuming we get an answer on the MAC issue and the terminology can we get a new version in two weeks.

Andrea presents her DSKPP slides, which re available at: http://www3.ietf.org/proceedings/09mar/slides/keyprov-2.ppt.

Changes since the last version:
 - Many changes to make document more readable and implementable
 - explained how protocol entities interact
 - reduced # of options for client authentication (complexity was because there were too many options)
 - modified conformance requirements on 3 key wrap mechanisms

Interoperability
 - There were at least 25 combinations for client authentication...it was way to hard we needed to distill it down to its bones.  Eliminated: client authentication that relied on client key/cert pair used with TLS cleint auth, combined authentication and PBKW since both use a one-time secret value, replace trigger nonce with authentication data.  Down to about 5 options now.

PSKC and DSKPP aligned on key wrap algorithm recommendations.

New comments:
- Mostly minor technical comments: needed to mention HTTP binding earlier, add some high level text describing flow and what attacker can do/can't do, remove tokenplatforminfotype, remove some notes, and align some terminology.

Next steps -08: do fixes, submit new draft

Philip Hoyer and Andrea describing terminology issues: 

Introduction: the issue is that there are two main documents (protocol and key) and they came from two different sources they used different terminology and it doesn't always align.

- Application usage: DSKPP and PSKC are used different because they really have different goals.

-Key package vs container:   DSKPP adopted key package because it was going to support either a container or key and ASN.1 can be either.  They're thinking they might go back to container.

- Policy is discussed in DSKPP but there's no a entry in PSKC.  PSKC willing to change

- Key protection methods vs key encryption: DSKPP is trying to be generic and PSKC isn't.  Would be great if PSKC could clearly identify them.

- DSKPP and PSKC use different words for basically the same thing.  Authors believe main misalignment stems from keypackage and keycontainer (as previsouly described).

- Pasi's proposed entity model: differentiate between hardware device and application that uses keys and introduction of managing authority entity.

So I didn't follow this as well as I should have: Pasi/Philip/Ming/Andrea/David Black: If you discuss it separately then you need different term if not then you don't.  Philip doesn't sound like he wants to model it and wants to get other's input. Ming thinks ... Andrea suggests that DSKPP can use either hardware or software device.  Entity models were removed from PSKC.  if they're the same will that help and whether the devicebinding addresses the issue around crypto module id.  David - i has been unhelpful that the cryptographic module from NIST has been adopted for both hardware/software.  Someone else suggested just considering them logical issues.  Pasi's point is that since the two documents are aimed at the same space they need to/must be aligned.  Many were confused by this.

Then we spun off for two hours on terminology.

spt