Subject: What preauth mechs?

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 06 Mar 2007 17:40:43 -0500

As I mentioned in my last note, Sam has convinced me that rather than an 
open-ended "work on any preauth" item or a much more limited "evaluate and 
propose, but don't do any work", we should plan to charter with a specific 
list of mechanisms to work on.  That leaves us with the task of decidin 
what should be in that list.

Of course, we're not talking only about "preauthentication" in the 
traditional sense, nor are we limited to extensions that make use of 
PA-DATA.  What we are talking about is anything that is designed to modify 
or augment the initial authentication process in order to protect users' 
passwords or eliminate their use altogether.

We've seen a number of items, some of which were old items in this WG, and 
some of which are brand new.  I've listed below all of the current 
proposals I can remember; please speak up if you have one not listed.  Note 
that there is some overlap between some of these:

    draft-ietf-krb-wg-preauth-framework-04.txt
    draft-ietf-krb-wg-hw-auth-04.txt
    draft-richards-otp-kerberos-01.txt

What I'd like to hear from the working group is comments on which of these 
should or should not be adopted, and why, and who is willing to contribute 
to and review them.

-- Jeff

---

From: "Richards, Gareth" <[email-masked]>
Date: Wed, 7 Mar 2007 12:31:43 -0000

I would give a vote for draft-richards-otp-kerberos-01.txt.  

We remain committed to continue driving the OTP work and so will be
wlling to contribute should it become part of the charter/a work item
for the group.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Jeffrey Hutzelman
> Sent: 06 March 2007 22:41
> To: [email-masked]
> Cc: Jeffrey Hutzelman
> Subject: What preauth mechs?
> 
> As I mentioned in my last note, Sam has convinced me that 
> rather than an open-ended "work on any preauth" item or a 
> much more limited "evaluate and propose, but don't do any 
> work", we should plan to charter with a specific list of 
> mechanisms to work on.  That leaves us with the task of 
> decidin what should be in that list.
> 
> Of course, we're not talking only about "preauthentication" 
> in the traditional sense, nor are we limited to extensions 
> that make use of PA-DATA.  What we are talking about is 
> anything that is designed to modify or augment the initial 
> authentication process in order to protect users' 
> We've seen a number of items, some of which were old items in 
> this WG, and some of which are brand new.  I've listed below 
> all of the current proposals I can remember; please speak up 
> if you have one not listed.  Note that there is some overlap 
> between some of these:
> 
> What I'd like to hear from the working group is comments on 
> which of these should or should not be adopted, and why, and 
> who is willing to contribute to and review them.
> 
> -- Jeff
> 
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Mar 2007 23:28:41 -0500

As an individual, I give a vote for
draft-ietf-krb-wg-preauth-fw-04.txt plus a requirement that anything
the group does that uses padata for pre-authentication be converted to
being a FAST factor.  I think that will solve a lot of our concerns
with the OTP mechanism and may make the need for hw-auth go away
completely.
(I'm not sure about the last part--perhaps otp+fast makes hw-auth go away).

Note that I have nothing against hw-auth; I just think we may have
already folded in Matt's main idea into FAST.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 8 Mar 2007 00:02:54 -0500 (EST)

On Wed, 7 Mar 2007, Sam Hartman wrote:

> being a FAST factor.

In fact, I think that's an important question to consider almost before we
think too hard about individual extensions.  Of course, the framework is
not a done deal - it would be a work item of this working group, which we
have the ability to review and change.

Speaking as an individual, I'm inclined to agree with Sam.  Our experience
with RFC3961 demonstrated that a carefully-designed framework can make it
a lot easier to think about protocol design; once you've demonstrated that
the abstractions provided by the framework have certain properties, you
can assume those properties in analyzing the rest of the protocol.

PKINIT teaches us another important lesson.  We spent several years
working on PKINIT, which is essentially a full-blown preauth mechanism
which provides several of the facilities described in preauth-fw, and as a
result it is quite complex.  As a result the design was quite difficult to
analyze.  In fact, an earlier draft contained a significant flaw which
might have been more easily recognized and understood given the structure
of preauth-fw's model.  In addition, following the framework might well
have led to a more modular design involving separable components which
could have been reused.

-- Jeff