Subject: [Ietf-krb-wg] OTP and processing delays

From: [email-masked]
Date: Tue, 7 Jun 2011 17:09:23 -0400 (EDT)

It's my understanding that commercial OTP servers sometimes impose
processing delays on the order of one to several seconds, for reasons
I don't completely understand.

Kerberos clients will typically move on to a second KDC after 1-3
seconds, because they have no idea whether the first KDC is alive and
they don't want to impose a long fallback delay on clients.  This
imposes additional work on the KDC infrastructure.  (If there is only
one KDC, the client will typically retransmit to the same KDC, which
isn't a big deal if the KDC has a proper lookaside cache.)

I can think of many ways of addressing this, including ignoring the
problem.  One possible way is for PA-OTP-CHALLENGE to include an
estimate of the KDC's processing time for the actual request.  After
transmitting its second AS request with PA-OTP-REQUEST, the client
would wait for at least that delay before trying a different server.

I'm not sure if I think this is the best option, but I was curious if
anyone else implementing OTP had run into this consideration and had
similar thoughts.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 07 Jun 2011 23:29:47 +0200

> anyone else implementing OTP had run into this consideration and had

My reaction would instead be to disable the client policy to move on to
a second KDC, at least when OTP verification is used.  The policy seems
like an heritage from older times were the KDC processing times could be
assumed to be instant.  Using TCP helps to resolve issues with lost UDP
messages.

/Simon

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 20 Jun 2011 14:42:01 -0700

Agree that TCP helps.

I think in general that new preauth mechanisms should be able to reset the timeouts (perhaps in response to data in the protocol).  I do not think that timeouts and failover should be disabled though.  

Suppose the OTP system is slow, like 5+ seconds say.  Now suppose the first KDC goes down after telling the client to wait.  The combination may make the client slow, but it should not make the client fail, or hang forever.

> assumed to be instant.  Using TCP helps to resolve issues with lost UDP

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: <[email-masked]>
Date: Mon, 27 Jun 2011 11:10:03 -0400

SecurID at least does have a configurable delay (2s by default) that could potentially cause this problem in some situations.

An estimated response time could easily be added to the OTP-TOKENINFO of the PA-OTP-CHALLENGE as suggested.  Maybe something like:

         maxResponseTime  [8] Int32                    OPTIONAL

--Gareth

> -----Original Message-----
> From: [email-masked] [mailto:ietf-krb-wg-
> [email-masked]] On Behalf Of Henry B. Hotz
> Sent: 20 June 2011 22:42
> To: Simon Josefsson
> Cc: [email-masked]
> Subject: Re: [Ietf-krb-wg] OTP and processing delays
>
> Agree that TCP helps.
>
> I think in general that new preauth mechanisms should be able to reset
> the timeouts (perhaps in response to data in the protocol).  I do not
> think that timeouts and failover should be disabled though.
>
> Suppose the OTP system is slow, like 5+ seconds say.  Now suppose the
> first KDC goes down after telling the client to wait.  The combination
> may make the client slow, but it should not make the client fail, or
> hang forever.
>

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Jun 2011 11:40:43 -0400

As an individual.

>From an implementation standpoint, I'm uncomfortable with a
preauth-specific mechanism for carrying information to change the
retransmission algorithm.  I'd rather see a mechanism-independent way of
conveying information to the client.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Mon, 27 Jun 2011 11:42:55 -0400

I was hoping for the same but I am not sure if it can be done since with OTP at least, the delay would be OTP algorithm dependent.

> From: Sam Hartman [mailto:[email-masked]]
> Sent: 27 June 2011 16:41
> To: Richards, Gareth
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Jun 2011 10:52:00 -0500

> conveying information to the client.

Agreed.

This could be done with a new error code and a KRB-ERROR with the
estimated wait time being given in either a PA element or in the
e-data field of the KRB-ERROR.

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Mon, 27 Jun 2011 11:52:56 -0400

> conveying information to the client.

I mostly agree.  Without strong support for handling this problem at the
mechanism level, I wouldn't suggest adding the field to the challenge.

A mechanism-independent way of conveying this could be a KDC error for
"in progress, please allow N seconds for processing".  You'd need some
way for the client to indicate that it understands this new KDC error,
such as a request flag, so that you don't cause old clients to abort the
exchange.

Also, it may be possible to handle this issue within the client
implementation without protocol extensions.  If a client isn't doing
optimistic preauth, it gets an immediate response to its first request
with a preauth-required error.  So for its second request, the client
knows that a particular KDC address is alive.  If it maintains the
necessary state, the client can glue itself to that KDC address for a
while (say, a minute) before giving up or trying other addresses.

(A minute is way more than enough for OTP, but I've heard proposals of
"text the principal's phone and get a response" for preauth; for that, a
minute might not be long enough.)

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Jun 2011 13:48:32 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    Greg> On Mon, 2011-06-27 at 11:40 -0400, Sam Hartman wrote:
    >> retransmission algorithm.  I'd rather see a mechanism-independent
    >> way of conveying information to the client.

    Greg> I mostly agree.  Without strong support for handling this
    Greg> problem at the mechanism level, I wouldn't suggest adding the
    Greg> field to the challenge.

    Greg> A mechanism-independent way of conveying this could be a KDC
    Greg> error for "in progress, please allow N seconds for
    Greg> processing".  You'd need some way for the client to indicate
    Greg> that it understands this new KDC error, such as a request
    Greg> flag, so that you don't cause old clients to abort the
    Greg> exchange.

We could also just have a padata returned with the challenge indicating
the expected wait time No reason to introduce a new packet.

I agree that some mechanism in the KDC needs to communicate the
OTP-specific wait time to the KDC's mechanism-independent part.  What I
want to avoid is having to have special logic on the client that pulls
that from the mechanism-dependent part into mechanism-independent code.

I don't really object to a new error, but it seems overly chatty from a
networking standpoint.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 27 Jun 2011 12:32:38 -0700

No problem with a general-prupose "wait" message.  I seem to have run into a bunch of cases where default timeouts don't work recently:  OTP, KX509 (query a back-end LDAP which usually has a multi-second timeout itself), and worst of all kpasswd.  In the latter case I've found that the back-end database operations require caching in order to avoid client timeouts.  I can also imagine someone wanting to query an external back-end for authorization data before issuing a ticket and needing an extended timeout for that reason.

The length and reason for the wait are going to be protocol-specific.  IMO the client should not allow the service to say "wait" more than once, but I'm curious what other people think on that point?

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Jun 2011 16:26:39 -0500

> The length and reason for the wait are going to be protocol-specific.  IMO the client should not allow the service to say "wait" more than once, but I'm curious what other people think on that poin…

Let the user decide when to stop waiting -- they do anyways :)
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg