Subject: [Ietf-krb-wg] Some Comments on preauth framework and OTP

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 26 May 2010 00:20:20 -0500

I don't think this is actually a problem.  Just a sort of philosophical inconsistency.

The preauth framework (FAST) only actually defines a request and a reply message.  It, fairly explicitly, expects that the client and server will both know when they are doing FAST as opposed to more traditional exchanges.  I don't believe there is a real attempt to define a functional "use FAST" error response if a client tries a no-preauth AS-REQ.  Please correct me if I'm wrong and have overlooked something.

The OTP preauth draft, in contrast, defines a response to be given to a no-preauth AS-REQ which is very similar in style to the traditional INFO2 error response.  It gets packaged into a FAST reply, giving the client what it needs to complete the authentication properly.  The overall 4-message exchange looks functionally equivalent to a traditional AS-REQ/ERROR/AS-REQ/AS-REP exchange with timestamp preauth.

I guess I haven't actually asked a question, and I don't have a specific question.  I'm just wondering if this stylistic difference is a symptom of some design disconnect which might actually be a problem.  Or, conversely, does it indicate an area where one or the other of the drafts could use some more explanation?  Or, on the third hand, is it not a problem and I just need to study the drafts some more?
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Wed, 26 May 2010 11:16:52 -0400

On Wed, 2010-05-26 at 01:20 -0400, Henry B. Hotz wrote:
> I don't believe there is a real attempt to define a functional "use
> FAST" error response if a client tries a no-preauth AS-REQ.  Please
> correct me if I'm wrong and have overlooked something.

6.4.2: "As with all pre-authentication types, the KDC SHOULD advertise
PA-FX-FAST in a PREAUTH_REQUIRED error".

It's not ideal to upgrade to FAST this way, since an attacker could
strip out the PA-FX-FAST.  But it does work in MIT's implementation.
(The more ideal scenario is that you did FAST negotiation when you
obtained the armor ticket, and know a priori that you can use FAST.)

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 27 May 2010 00:26:51 -0500

> PA-FX-FAST in a PREAUTH_REQUIRED error".

6.4.5:  "Typically, a client will know that FAST is being used before a request containing PA-FX-FAST is sent."  ;-)

A more substantive reason I don't think it's so clear is that just advertising PA-FX-FAST as described doesn't provide enough information to know what FAST factors are available, or how to use them if they take extra options (which seems likely).  Perhaps I'm really supposed to interpret that as support for encrypted challenge?

The OTP FAST factor, which seems like it ought to fit this model, instead starts it's FAST conversation with a reply, not a request.  Within OTP this makes sense because the KDC may need to distinguish users that must/may use OTP vs ones that only have ordinary passwords.  (Hmm.  Does the reply key derivation work if there was no request?  It's late, so excuse me for not checking.)

If the real, practical, useful meaning of advertising PA-FX-FAST is that the KDC supports encrypted challenge (because that's the only mandatory FAST factor) then I think the draft could use some clarification.

> obtained the armor ticket, and know a priori that you can use FAST.)

Yeah, you're not safe from that kind of thing until you're inside FAST, but you can't get there unless you've already done some exchange with the KDC (to get a TGT to generate your first armor key).  

Given that, does the only real-world scenario for engaging FAST's only mandatory FAST factor require that you know you're doing FAST before you start?  I'm thinking it does, because why else would an initial authentication process begin by getting a TGT for someTHING (not even an actual user) that isn't the user you're trying to authenticate?  Or does it mean that an encrypted challenge initial authentication should take three round trips?

I don't mean that to be as critical as it probably sounds.  FAST is by definition a framework and doesn't specify how it is to be used.  Currently we only have two FAST factors (encrypted challenge and OTP) that we can use as real illustrations.  Even if the specification were perfect, I need to understand how it will interact with its surroundings.

---

From: Greg Hudson <[email-masked]>
Date: Thu, 27 May 2010 10:47:38 -0400

> 6.4.5:  "Typically, a client will know that FAST is being used before
> a request containing PA-FX-FAST is sent."  ;-)

> A more substantive reason I don't think it's so clear is that just
> advertising PA-FX-FAST as described doesn't provide enough information
> to know what FAST factors are available, or how to use them if they
> take extra options (which seems likely).  Perhaps I'm really supposed
> to interpret that as support for encrypted challenge?

If you're upgrading to FAST, you need to start over, which introduces an
extra round trip.  Doing encrypted challenge might be problematic
because the "right" FAST factor might not require a password.

> Given that, does the only real-world scenario for engaging FAST's only
> mandatory FAST factor require that you know you're doing FAST before
> you start?  I'm thinking it does, because why else would an initial
> authentication process begin by getting a TGT for someTHING (not even
> an actual user) that isn't the user you're trying to authenticate?  Or
> does it mean that an encrypted challenge initial authentication should
> take three round trips?

Yes, three round trips.  The best-case scenario without optimistic
preauth is:

  C->K: AS-REQ for host princ
  K->C: AS-REP for host princ, with FAST negotiation
  C->K: FAST AS-REQ for user princ
  K->C: FAST KRB-ERROR with preauth-required list
  C->K: FAST AS-REQ for user princ with encrypted timestamp
  K->C: FAST AS-REP

There is also a scenario with four round trips, where the KDC doesn't
implement FAST negotiation but does support FAST (e.g. MIT krb5 1.7).
In that case, the client does a non-FAST AS-REQ for the user princ, sees
PA-FX-FAST in the response, and starts over with a FAST-protected
AS-REQ.  This scenario is subject to downgrade attacks.

This same pam_krb5 would work with a non-FAST-enabled KDC, although
still with the extra round trip to get an armor ticket which isn't used.

> I don't mean that to be as critical as it probably sounds.  FAST is by
> definition a framework and doesn't specify how it is to be used.
> Currently we only have two FAST factors (encrypted challenge and OTP)
> that we can use as real illustrations.  Even if the specification were
> perfect, I need to understand how it will interact with its
> surroundings.

(Warning: topic drift!)

My main concern is that the preauth framework says new preauth
mechanisms should be specified as FAST factors, but FAST factors don't
work if FAST is not in use.  FAST can only be used if:

  1. An armor ticket can be obtained (only applicable to privileged
initiators on keyed hosts).
  2. Anonymous PKINIT is used to obtain an armor ticket (expensive in
CPU).

In the future there might be an EKE armor, but that's still expensive in
CPU (though perhaps not quite as much as anonymous PKINIT).  As an
implementor, I'm not sure if I can make a public key operation per user
AS request the default mode of operation without creating performance
problems.