[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [KEYPROV] PSKC scope and interoperability
Pasi,
Comments [PH] inline
-----Original Message-----
From: keyprov-bounces at ietf.org [mailto:keyprov-bounces at ietf.org] On
Behalf Of Pasi.Eronen at nokia.com
Sent: Monday, August 11, 2008 1:50 PM
To: keyprov at ietf.org
Subject: [KEYPROV] PSKC scope and interoperability
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.
[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?
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.
[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">
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.
[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
(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...)
[PH] happy to discuss
Best regards,
Pasi
_______________________________________________
KEYPROV mailing list
KEYPROV at ietf.org
https://www.ietf.org/mailman/listinfo/keyprov
_______________________________________________
KEYPROV mailing list
KEYPROV at ietf.org
https://www.ietf.org/mailman/listinfo/keyprov