Transcript Dynamic Symmetric Key Provisioning Protocol (DSKPP) Andrea Doherty Mingliang Pei

Dynamic Symmetric Key
Provisioning Protocol (DSKPP)
Andrea Doherty
Mingliang Pei
Salah Machani
Magnus Nyström
IETF 73
Minneapolis, USA
19 November 2008
Document Status
• Version -06 submitted November 3rd
– Addressed Philip Hallam-Baker’s comments
– Addressed most (but not yet all) of Sean Turner’s
comments
– Addressed Magnus’ concern about AuthData calculation
– Addressed Ming’s request for AuthCode extensibility
• Version -06 since November 3rd
– Received proposal for support of key confirmation at the
crypto module from Ming
– Received major comments from Pasi Eronen
Resolved Issues (i)
• Authentication Code Format
– As of version -05 authentication code format is TLV-based
– Client ID and password length are left up to the
implementers
– As of version -06 <AuthenticationDataType> is extensible:
<xs:choice>
<xs:element name="AuthenticationCodeMac“
type="dskpp:AuthenticationMacType"
<xs:any namespace="##other" processContents="strict" />
</xs:choice>
Resolved Issues (ii)
• Authentication Data calculation
– Magnus raised concern about vulnerability to MITM
caused by K being optional in the four-pass
• K_AC = PBKDF2(AC->password, R_C || [K], iter_count, 16)
• K is OPTIONAL only in four-pass where no K_SHARED is used.
• Resolution:
– K_AC = PBKDF2(AC->password, R_C || K, iter-count, 16)
– In four-pass one of the following values for K MUST be
used:
• The public key of the DSKPP server (K_SERVER); or (in the preshared key variant)
• The pre-shared key between the client and the server (K_SHARED)
Open Issues - #1
• Pasi pointed out that the document doesn’t explain
how protocol entities interact with the outside world
– Since DSKPP is an application-layer protocol it interacts
with a wider set of entities outside the protocol in more
complex ways than, e.g., lower layer protocols like the
transport layer (which just “send opaque data bytes”)
– Addressing this is critical for implementations and
interoperability
• Consider a protocol model in RFC 4101 sense:
– Explain how "protocol black box" interacts with the rest of
the world
– Provide a high-level view of the protocol internals (but
omit the details that could be changed without the world
external to DSKPP noticing)
Open Issues - #2
• Pasi pointed out that the document describes a
framework more than a protocol
– Too much flexibility makes the document hard (if not
impossible) to understand, much less implement
– There are too many options to make implementations
interoperable
Open Issues - #2 (cont’d, ii)
• Example given was the six ways a DSKPP client can be
authenticated:
– Authentication Code (one-time secret value, delivered to the user outof-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 (CTLS)
– Client certificate/key pair, used inside DSKPP in the Key Transport
Profile.
– Pre-existing symmetric key
• This many options means that there are at least 25
different combinations one can use to implement
client-side authentication!
Open Issues - #2 (cont-d, iii)
• Pasi asked for the first document to support only a couple of
the most important combinations
– Defer the rest to separate document(s) later
• Consider reducing/combining options, for example:
– Eliminate “Client certificate/key pair, used with TLS client
authentication”; this would reduce number of combinations from 25
to 8. There is consensus from the authors that this would be
acceptable for two-pass since, e.g., most implementations find CTLS
too costly/complex to deploy. Should consider it also for four-pass.
– Combine authentication code and PBKW since both use a one-time
secret value
– Could remove trigger nonce from <KeyProvTrigger>, and rely on
manually entered Authentication Code instead, or <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
Open Issues - #3
• Key Confirmation to the Crypto Module in two-pass protocol
– SIM and TPM chip vendors have expressed interest in implementing
DSKPP, but since these can have pre-embedded trust points,
expectation is for key confirmation at crypto module, i.e., not to limit
key confirmation at DSKPP client
• Creates another option that must be considered for inclusion
in the protocol as we work to narrow the scope
• If assume trust anchor resides in the crypto module, this
changes the original protocol assumption and could create
significant change to the protocol
– PKIX members on TAM work should be consulted
– Must consider whether DSKPP is appropriate for this environment, or
an extension to an existing PKI protocol
Open Issues - #3 (cont’d)
• In the 4-pass, DSKPP uses the server public
K_SERVER for R_C encryption, implying the use of
trust anchors in the crypto module as per this note:
– "If K is equivalent to K_SERVER, then the cryptographic
module SHOULD verify the server's certificate before using
it to encrypt R_C in accordance with [RFC5280]."
– How this is done is not defined.
• Salah and Ming suggested that we could do the same
for 2-pass and encrypt the R_C in the ClientHello
using K_SERVER.
– In this case, e.g., <KeyProvTrigger> may be used to pass
the K_SERVER, the server 's cert or the server's public key
ID/certificate ID to the client, then to the crypto module.
– MITM attack can be defeated in this process only if the
server public key/certificate is pre-loaded in the
CryptoModule and verified.
Next Steps
• Request support with open issues
• Request teleconferences to:
– Address better abstraction of the protocol model
in terms of interacts with outside world
– Narrow options down to a core set; decide which
should/could be deferred to later document(s)
• Submit another draft before the end of the
calendar year that addresses:
– The remainder of Sean Turner’s comments
– Open issues