Subject: [KEYPROV] DSKPP -06

From: <[email-masked]>
Date: Tue, 11 Nov 2008 15:51:38 +0200

Andrea and others,

I've been going through draft -06 of DSKPP, not doing a detailed
review, but rather trying to identity the most important areas that
still need work, and thinking what could be done about them.

One of the two main problem I see is that the document doesn't say
much about how the DSKPP protocol entities interact with the rest of
the world. While some lower layer protocols (e.g. in transport layer)
have quite simple interfaces (for them, "rest of the world" is just
the lower and upper layer protocol, and the interface is usually
"send/receive opaque data bytes" plus some connection management),
application-layer protocols like DSKPP interact with much wider set of
entities outside the protocol, and in more complex ways than just
"send opaque data bytes".

I will send some rough text before the Minneapolis meeting to
better clarify what I mean here, and what I'd suggest putting
in the document -- if we can somehow tackle the second issue (below), 
this won't be overly complicated.

However, writing that text is significantly complicated by what
is -- in my opinion -- the second main problem: There's a large number
of options everywhere, leading to a very large number of protocol
variants that differ in message contents and/or their processing and/or 
how DSKPP protocol entities interact with the rest of the world.

For example, considering just how the "client side" of DSKPP 
can be authenticated, we seem to have at least six basic options:

- Authentication Code (one-time secret value, delivered to the 
  user out-of-band before DSKPP starts)
- Passphrase-Based Key Wrap (another one-time secret value, 
  delivered to user out-of-band before DSKPP starts)
- Web-based authentication (authenticate user using any web 
  mechanism, then use TriggerNonce as one-time secret value).
- Client certificate/key pair, used with TLS client authentication.
- Client certificate/key pair, used inside DSKPP in the Key 
  Transport Profile.
- Pre-existing symmetric key.

And it seems at least the following combinations are also
look valid (possibly -- I haven't worked out all of these):

- Authentication Code (AC) + Passphrase-Based Key Wrap (PBKW)
- Web-Based authentication (WBA) + AC
- WBA + PBKW
- WBA + AC + PBKW
- Client certificate/key pair in TLS (CTLS) + AC
- CTLS + PBKW
- CTLS + AC + PBKW
- CTLS + WBA
- CTLS + WBA + AC
- CTLS + WBA + PBKW
- CTLS + WBA + AC + PBKW
- Client certificate/key pair in key transport profile (CTP) + AC
- CTP + CTLS
- CTP + WBA
- CTP + WBA + AC
- CTP + WBA + CTLS
- CTP + WBA + CTLS + AC
- Pre-existing symmetric key  in key wrap profile (KW) + CTLS
- KW + WBA
- KW + WBA + CTLS

I'm counting here over 25 ways to authenticate the "client side", all
with slightly different message contents, message processing, and
interaction with the rest of the world (and some of them apply to both
two-pass and four-pass, leading to even more protocol variants).  
(And I'm not even counting everything -- we could currently do passphrase
based key wrap in two ways, one in DSKPP level, another in PSKC,
or possibly even both -- or anything related to "server side" 
authentication.)

I think this number of protocol variants is way too large to be
understood by the people who'll read this document, and it's not 
very likely to further interoperability, either. 

If the first document coming out of KEYPROV would support, say,
only the couple of most important variants (and the rest could be 
in separate document(s) later), which of these are the most important?

Could we combine some of these somehow? Perhaps the KeyProvTrigger
message could deliver an Authentication Code (instead of TriggerNonce)
and from there on, the protocol would continue the same as with manually 
entered authentication code? Can we combine authentication code and
passphrase-based keywrap somehow -- both use a one-time secret value?
What about the two ways of using client-side certificates? 

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

---

From: "Pei, Mingliang" <[email-masked]>
Date: Tue, 11 Nov 2008 12:50:20 -0800

Hi Pasi,

Thank you for the detail comments. Here are some of my thoughts on some
of your suggestions.

1. With the default package PSKC, the key wrap profile used in DSKPP
actually mean the one to use in PSKC. PSKC and DSKPP are aligned in this
aspect.

2. I favor your suggestion on simplifying the AC and passphrased based
profile. When an AC is given, the password portion of AC could be used
as the passphrase in general. I consider that scenarion the typical
case. Maybe we should make this a common recommendation in the spec. But
I am not sure that it should limit to this scenario: when a passphrase
based key wrap profile is used, the AC code will be the passphrase.

3. The client certificate profile case simplication is meaningful to me
as well. We can specify only the option that uses client certificate in
message protocol with signed data. The option of relying on SSL client
auth with a certificate can be ignored. When the client certificate is
used to transport key back to the server, the client signing in a
message doesn't increase the complexity while the response message
contains PKI encrypted data. Mixing SSL client auth in transport layer
and the encrypted XML element in response message don't seem to be the
better than the other option where all authentication data are carried
in the protocol messages.

- Ming

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Tuesday, November 11, 2008 5:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: [KEYPROV] DSKPP -06

Andrea and others,

I've been going through draft -06 of DSKPP, not doing a detailed review,
but rather trying to identity the most important areas that still need
work, and thinking what could be done about them.

One of the two main problem I see is that the document doesn't say much
about how the DSKPP protocol entities interact with the rest of the
world. While some lower layer protocols (e.g. in transport layer) have
quite simple interfaces (for them, "rest of the world" is just the lower
and upper layer protocol, and the interface is usually "send/receive
opaque data bytes" plus some connection management), application-layer
protocols like DSKPP interact with much wider set of entities outside
the protocol, and in more complex ways than just "send opaque data
bytes".

I will send some rough text before the Minneapolis meeting to better
clarify what I mean here, and what I'd suggest putting in the document
-- if we can somehow tackle the second issue (below), this won't be
overly complicated.

However, writing that text is significantly complicated by what is -- in
my opinion -- the second main problem: There's a large number of options
everywhere, leading to a very large number of protocol variants that
differ in message contents and/or their processing and/or how DSKPP
protocol entities interact with the rest of the world.

For example, considering just how the "client side" of DSKPP can be
authenticated, we seem to have at least six basic options:

And it seems at least the following combinations are also look valid
(possibly -- I haven't worked out all of these):

I'm counting here over 25 ways to authenticate the "client side", all
with slightly different message contents, message processing, and
interaction with the rest of the world (and some of them apply to both
two-pass and four-pass, leading to even more protocol variants).  
(And I'm not even counting everything -- we could currently do
passphrase based key wrap in two ways, one in DSKPP level, another in
PSKC, or possibly even both -- or anything related to "server side" 
authentication.)

I think this number of protocol variants is way too large to be
understood by the people who'll read this document, and it's not very
likely to further interoperability, either. 

If the first document coming out of KEYPROV would support, say, only the
couple of most important variants (and the rest could be in separate
document(s) later), which of these are the most important?

Best regards,
Pasi