Subject: Issues to discuss with draft-ietf-krb-wg-preauth-fw

From: Sam Hartman <[email-masked]>
Date: Tue, 13 Mar 2007 14:54:03 -0400

I'm speaking here as a co-author and individual, not an AD.

In the editing pass for IETF 68, Larry and I identified a number of
issues we'd like to discuss with the WG.  These issues are outlined
using anchors in the draft.  I've briefly described each issue below.
The anchor clearly points out what text in the draft applies to the
issue.

   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
   (defined in Section 6.3) for pre-authentication configurations that
   use multi-round-trip mechanisms; see Section 3.4 for details of that
   case. [[anchor3: Is it desirable to define a new error code for this?
   Probably but we need to call out to the WG.]]

Does the WG want to define a new error code for the second and
following round trip in a preauth conversation or do we want to reuse
the preauth_required error?  I think defining a new error code makes a
lot of sense and propose we adopt the text as written.

   [[anchor6: Containers like this need more thought.  For example if
   you are constructing an authentication set do you expect to use a
   strengthen reply key mechanism in conjunction with something else, do
   you include the something else in the hint of the strengthen
   mechanism or as its own entry.  It's easier to configure and express
   the authentication set as its own entry.  However if you do that' the
   composition of the mechanisms looks in practice than it appears in
   the authentication set.]] 

This is a complicated issue.  In order to follow extensibility rules,
you need to have some pre-auth mechanisms that include a sequence of
pre-auth mechanisms internally.
See section 4.2 for a discussion.  
However there's another case where you want to have a sequence of
pre-auth mechanisms: when you want to tell someone a set of mechanisms
they must all satisfy in order to be authenticated.
The set mechanism might be used to say that you need to perform smart
card auth followed by biometric auth in order to get a ticket.

These two combinations interact.  Let's say we have a dh-strengthen
mechanism that somehow uses DH to strengthen a reply key.  Do you want
to ask the client to do {dh-strengthen, smart card} meaning that they
should involve both mechanisms or do you want to be more accurate and
say {dh-strengthen(smart card)} meaning that a smart card mech should
be done within the dh-strengthen.

This has implications for how hint data is constructed and how people
write their implementation loops--recursion vs iteration; how much
unrolling you do.

   Mechanisms implementing this facility and including a typed hole for
   additional padata MUST checksum that padata using a keyed checksum or
   encrypt the padata. [[anchor7: Why?  I suspect there's an obvious
   attack here but I need to work through it and add detail.  In
   particular, it seems that a checksum at the end should be
   sufficient.]]

I'm not sure  why I made that security requirement when I wrote the
original text.
That's not really so much of an issue for the WG, although if anyone
can convince me the restriction is required or should be relaxed
please let me know.

   [[anchor11: Kerberos is stateless today.  We can either maintain that
   and store all the state in a cookie or change that and require
   clients go to the same KDC for future requests.  Consider how this
   interacts with proxies.  The rest of this section assumes we maintain
   the current model.]

Consider what happens when you have multi-round-trip mechanisms.  Do
you want to force everything to the same KDC it came from or do you
want to maintain the current model.  The really hard problem here is
how do you deal with replays.  There's been some interesting
discussion on this on the [email-masked] list because of a mechanism
someone was proposing there.
MIT has also run into problems internally deploying SAM2 because of
this problem.

   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
   contains the corresponding value of padata-type in PA-DATA [RFC4120].
   Associated with the pa-type is a pa-hint, which is an octet-string
   specified by the pre-authentication mechanism.  This hint may provide
   information for the client which helps it determine whether the
   mechanism can be used.  For example a public-key mechanism might
   include the certificate authorities it trusts in the hint info.  Most
   mechanisms today do not specify hint info; if a mechanism does not
   specify hint info the KDC MUST NOT send a hint for that mechanism.
   To allow future revisions of mechanism specifications to add hint
   info, clients MUST ignore hint info received for mechanisms that the
   client believes do not support hint info. [[anchor12: What if you
   have a padata type as the first member of a set that requires a
   challenge.  For example SAM assumes that the KDC sends a challenge to
   the client initially.  That's not a pa-hint; that's a pa-value.  How
   do you convey that data with this?]]

We need to resolve how pa-hints interact with initial challenges.
They are not really the same thing.  Perhaps you need both.

[[anchor13: The PA-SET appears
   only in the first message from the KDC to the client?  In particular,
   the client should not be prepared for the future authentication
   mechanisms to change as the conversation progresses.  I think this is
   correct; we should discuss and if the WG agrees the text should
   reflect this.]]

Hopefully people agree.

   [[anchor14: It's much easier to design UIs if you can determine ahead
   of time what all the elements of your dialogue will need to be.  If
   we mandate that the pa-hints need to be sufficient that you can
   determine what information you will require from a user ahead of time
   we can simplify the UI for login.  I propose that we make this
   requirement.  WG agreement required.]]

This would be a great help for UI designers.  But it does mean that
your first message needs to contain any challenge prompts etc that you
will ask the user for.  The disadvantage is that for example if you
have multiple OTP tokens you will need to ask all the challenges at
once.  Similarly, you cannot have some authentication mechanism whose
existence is only disclosed once other authentication happens.
However without this, MIT at least has found designing UI to be very
challenging.
6.5.2.2.  Key-based Armors

   The FX_FAST_ARMOR_KEY_ID armor type is used to carry an identifier of
   a key that is shared between the client host and the KDC.  The
   content and the encoding of the armor-data field of this armor type
   is a local matter of the communicating client and the expected KDC.
   The FX_FAST_ARMOR_KEY_ID armor is useful when the client host and the
   KDC does have a shared key and it is beneficial to minimize the
   number of messages exchanged between the client and the KDC, namely
   by eliminating the messages for obtaining a host ticket based on the
   host key. [[anchor19: Do we believe this has sufficient value to
   specify or do we want to assume all armor comes from tickets?]]

Does the WG believe that shared long-term keys are appropriate for
associations between a client implementation and the KDC to protect
pre-auth?
6.5.5.  Error Messages used with Kerberos FAST

   If the Kerberos FAST padata was included in the request, unless
   otherwise specified, the e-data field of the KRB-ERROR message
   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
   [RFC4120], where a PA_FX_FAST padata element is included and it
   contains the DER encoding of the type PA-FX-FAST-REPLY.  If the
   e-data field of the KRB-ERROR message contains the DER encoding of a
   TYPED-DATA, a typed data element TD_FX_FAST SHOULD be included in the
   e-data if the Kerberos FAST padata is included in the request, and
   the corresponding data-value field [RFC4120] contains the ASN.1 DER
   encoding of the type PA-FX-FAST-REPLY.  In other words, the typed
   data element type TD_FX_FAST is allocated to encapsulate the FAST
   reply message in the error responses.  If a PA-FX-FAST-REPLY is not
   included in the error reply, it is a matter of the local policy on
   the client to accept the information in the error message without
   integrity protection. [[anchor21: Why do we want padata in arbitrary
   error responses?  What if the KDC cannot generate a fast reply
   because for example no armor nor state cookie was included in a
   request?  Also, we need to confirm that the WG is OK with a pre-
   authentication specification changing error returns for unrelated
   errors.]]

In particular, note that the current text causes errors unrelated to
pre-auth to suddenly be expected to have typed data simply because
FAST was used in one direction.
Is this what we want?