Subject: Preauth and the requirement for conjunction

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Oct 2004 16:27:35 -0400

Last IETF I was discussing the problem of how a clients should choose
what preauth to do given multiple choices.  The conclusion on the list
seemed to be that there was no good answer and that perhaps the server
should tell the client.

I have thought about the problem and concluded that we do need the
server to provide hinting information to the client.  We also need to
rethink the semantics of the padata field in the request.  

First let's see why things are complex.  It turns out that complexity
in preauth comes from two sources.  The first source of complexity is
any multi-round-trip mechanism.  You need to keep state on the client
for any such mechanism and you need to have a way for the client to
pass state to the KDC.  In addition, this generates some fairly
complex security requirements about when keys can be used that the
client and server must enforce.

The second source of complexity is choice between mechanisms.  Things
mostly work if there is only one type of preauth that is used for any
given principal.  However if there are multiple types of preauth that
could potentially succeed then you run into a two potential problems.
First, some of the preauth mechanisms that the client might try
involve prompting the user.  You don't want to prompt the user unless
you actually will end up using the information they supply.  Secondly,
because of security requirements, using one preauth mechanism at one
point in the process may make it impossible to use another preauth
mechanism later.  For example, once you have replaced the reply key
you cannot use a mechanism like encrypted timestamp.

So, we need to either decide that principals have only one preauth
that will work or we need to allow the KDC to tell the client what
combinations are valid.  I'm assuming that guaranteeing that
principals will only have one preauth is not an option.  I propose to
add a conjunction preauth; it contains a list of preauth types,
hinting data that may be useful to the client and initial data for the
first padata in the list.

In addition to this new padata type, we need to split out the handling
of the first message from all following messages.  ONly the first
message should contain this padata type.  I actually think that making
the first message special will significantly improve document flow.

This leavs us with the amazingly thorny question of what should the
client do if there are multiple preauths in the first message.  What
we want to say ideally is that the client should pick one.  This
probably creates an interop problem for existing clients which will
try to do all of them.  Also it does not work for non-preauth padata.

The closest semantics I have found so far are:

* a client can choose to process zero or more of the elements in the
  first
  padata.

  * The client should process any padata it understands that don't
    relate to
    preauthentication

    * The client should process one padata element that does relate to
    preauthentication

That's a mess.  Anyway I'm going to write up the conjunction and to
spit out the handling of the first message.  Thoughts on the rest of
this are appreciated.  I'm concerned that I may not be considering the
model correctly because there is a lot of complexity.

--Sam