Subject: [KEYPROV] PSKC scope and interoperability

From: <[email-masked]>
Date: Mon, 11 Aug 2008 15:50:28 +0300

Somem

Expanding on the things I commented in the Dublin meeting:

Scope and document title: I'd suggest limiting the scope of the
document (and perhaps adjusting the title accordingly) explicitly to
one-time password/challenge-response (and similar) tokens and their
backend servers.  Currently, some parts of the document suggest PSKC
could be used for anything involving symmetric keys, but many other
parts really assume the OTP/challenge-response token environment
(which e.g. has two parties -- token and backend server -- with very
different roles). Removing those assumptions would probably be a huge
effort and not really needed.

Interoperability: I expect the document to contain enough normative
text to produce interoperable implementations for some specific use
cases. This would mean e.g. specifying what attributes are (or are
not) included, and describing the exact semantics for them (in this
particular use case; for both the token and the back-end server, in
case the semantics differ -- as they probably do for some attributes).

One way to approach this would be to treat e.g. KeyAlgorithm URI (or
some new URI field) as "profile identifier", write a section
describing "how to write PSKC profiles" (what needs to be described in
addition to specifying the URI -- currently Section 8.4.4 assumes that
just the URI is enough), and then writing those profiles for some set
of URIs (perhaps those in Section 8.4.4). Other approaches may work
equally well -- I haven't done much thinking about the solutions yet.

Conceptual model / terminology: I'm not sure if the conceptual model
("Devices", "Cryptographic Modules", "Key Packages,", and "Tokens") is
completely aligned between DSKPP and PSKC. It also seems to be missing
one important concept (more below), and treat only "client-side"
things (while PSKC is also consumed by back-end servers).  About the
missing concept: I think it was Phillip who commented in Dublin about
the serial number -- for software tokens running on general-purpose
operating systems, is it the serial number of the software token (of
which there could be multiple on same host), or the "computational
platform" (e.g. iPhone)?  Explicitly adding "Computational platform"
(hardware and operating system) to the conceptual model could perhaps
clarify this situation regarding software tokens.

(My printed copy of PSKC -05 draft has *lots* of additional comments,
too, but they're mostly about some specific paragraph; we can discuss
those later...)

Best regards,
Pasi
_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: "Philip Hoyer" <[email-masked]>
Date: Mon, 11 Aug 2008 15:51:17 +0200

Pasi,
Comments [PH] inline

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Monday, August 11, 2008 1:50 PM
To: [email-masked]
Subject: [KEYPROV] PSKC scope and interoperability

Somem

[PH] I am not sure I agree, I am getting interest I this from people
where the keys are not really around authentication but it is still a
standard base format to transport symmetric keys directly or symmetric
key derivation information between two parties.

Maybe there are some aspects of it that can be more generalised. E.g.
instead of usage = 'OTP' we could change it to usage = 'authentication'

Could you go into more detail in terms of why you think it would be such
a big effort?

[PH] We might get the same pushback that we had for generic attributes
here.
Also Anders Rundgren sent an email where this profile negotiation could
be part of the protocol negotiation. E.g. what does the sending and
receiving party actually expect. Is this then part of PSKC or should
this be clearly in the domain of the protocol eg.g DSKPP. I am worried
about interoperability too and hence saw definitely the definition of
the semantics of a specific Data item. e.g. Counter as something that
should be included within PSKC. Because of this initially we had the
idea of the IANA registry of Data elements. But I agree that this would
not solve the problem of what data elements are needed for each key. So
maybe we do need an addition to the XML itself whereby under the
algorithm one could list the data items required ina . notation? For
example:

           <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
requires="Usage.ResponseFormat,Data.Secret,Data.Counter"
           KeyId="987654321">

[PH] Rob Philpott pointed this out and hence we added DeviceBinding to
the DeviceInfo element with the following description:
" <DeviceBinding> (OPTIONAL), the identifier that can be used to
      bind keys to the device or class of device.  When loading keys
      into a device, this identifier can be checked against information
      obtained from the device to ensure that the correct device or
      class of device is being used."

Maybe we need an iteration on this to make sure we have the right
elements and structure to be able to distinguish between serialnumber
and devicebinding/computationalplatform

[PH] happy to discuss

Best regards,
Pasi

---

From: <[email-masked]>
Date: Mon, 25 Aug 2008 15:32:04 +0300

Philip Hoyer wrote:

> where the keys are not really around authentication but it is still
> a standard base format to transport symmetric keys directly or
> symmetric key derivation information between two parties.
> 
> Maybe there are some aspects of it that can be more
> generalised. E.g.  instead of usage = 'OTP' we could change it to
> usage = 'authentication'
> 
> Could you go into more detail in terms of why you think it would be
> such a big effort?

Expanding the usage to "authentication" might be feasible (but then
it'd be good to describe what kind of non-OTP non-challenge/response
authentication is meant), but IMHO it would be a huge job to describe 
the semantics of all the data fields in a way that would also make 
sense for e.g. hard disk encryption or military T3 link encryptors 
(to give two examples of things that use symmetric keys, but are very 
different from authentication tokens). Such effort would also 
fall outside the current charter, which talks about "symmetric 
key authentication tokens".

>> One way to approach this would be to treat e.g. KeyAlgorithm URI
>> (or some new URI field) as "profile identifier", write a section
>> describing "how to write PSKC profiles" (what needs to be described
>> in addition to specifying the URI -- currently Section 8.4.4
>> assumes that just the URI is enough), and then writing those
>> profiles for some set of URIs (perhaps those in Section
>> 8.4.4). Other approaches may work equally well -- I haven't done
>> much thinking about the solutions yet.

> [PH] We might get the same pushback that we had for generic
> attributes here.  Also Anders Rundgren sent an email where this
> profile negotiation could be part of the protocol
> negotiation. E.g. what does the sending and receiving party actually
> expect. Is this then part of PSKC or should this be clearly in the
> domain of the protocol eg.g DSKPP. 

Currently, PSKC is also intended to be used without DSKPP; e.g.  for
bulk import/export. In this case, automatic negotiation would probably
be difficult -- if e.g. one OATH HOTP server exports things one way,
and another server expects to import them in some slightly different
way, things won't work.

> I am worried about interoperability too and hence saw definitely the
> definition of the semantics of a specific Data item. e.g. Counter as
> something that should be included within PSKC. Because of this
> initially we had the idea of the IANA registry of Data elements. But
> I agree that this would not solve the problem of what data elements
> are needed for each key. So maybe we do need an addition to the XML
> itself whereby under the algorithm one could list the data items
> required ina . notation?  For example:
>
> 

I don't think we need any formal notation here; it wouldn't capture
many of the important details anyway (e.g. for HOTP, only certain
subset of all possible ResponseFormat values make sense, and the
document needs to tell what those are).

Also, the descriptive text (and an example would be good, too) should
be in a specification document, not in IANA registry (IANA doesn't
need it). 

Best regards,
Pasi

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 25 Aug 2008 18:14:59 +0200

In the current DSKPP I-D there is a section with PKCS #11 interoperability.

In the current PSKC I-D there is support for [pre]setting PINs per key.

Although my PKCS #11 knowledge is limited, it seems that setting
initial PINs in PKCS #11 is per token which is not equivalent to a
key unless the token only holds exactly one key.

I discovered this while trying to use Mozilla's soft token PKCS #11.

Anders