Subject: Re: AD review of draft-ietf-krb-wg-otp-preauth

From: Sam Hartman <[email-masked]>
Date: Thu, 18 Aug 2011 17:27:03 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Sam Hartman <[email-masked]> writes:
    >> Actually, I have a question about interoperability here.
    >> 
    >> It's my assumption that a client of this specification needs to
    >> implement basically all the options:
    >> 
    >> * encrypted OTP values and values used for key derivation *
    >> separate pins and pins that are together * at least 4 pass mode
    >> 
    >> So that the server has flexibility to implement what its OTP
    >> token requires.
    >> 
    >> Are people assuming that it is acceptable to implement a client
    >> that only implements the facilities needed by one particular OTP
    >> token?

    Simon> Yes, and I believe that is unavoidable -- there is no way to
    Simon> properly test all features of any implementation without
    Simon> having some OTP token that excercises each feature.

OK.  That makes me very uncomfortable.  As an individual I'd prefer that
this draft not be published without a mandatory-to-implement subset.
My assumption was that the client needed to implement everything.
If that's not globally held I think we have much more work to do.

Please consider this an individual last call comment, not as a comment
as a chair.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Aug 2011 10:48:09 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:
87
    Greg> On Fri, 2011-08-19 at 08:53 -0400, [email-masked] wrote:
    >> I had always thought the same way as Sam, that clients would be
    >> required to implement all of the options since there appears to
    >> be no other way for them to support different disconnected token
    >> types.  The specification was intended to be token independent
    >> and the assumption was always that the clients would also be.

    Greg> I agree, at least at the general level and for disconnected
    Greg> tokens.  (Does nextOTP make any sense for disconnected
    Greg> tokens?)

I think you prompt the person to hit the next value button

---

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Aug 2011 12:28:04 -0400

My take as an individual is that most of the people who have read the
draft and commented here read it the same way.  It's up to the AD to
decide if things are clear enough but I'm not pushing for any specific
change and would be happy if no change were made on this point.  I would
not push back against any clarity the AD or IESG request in this space.

---

From: <[email-masked]>
Date: Fri, 19 Aug 2011 08:53:19 -0400

> Please consider this an individual last call comment, not as a comment

I had always thought the same way as Sam, that clients would be required to implement all of the options since there appears to be no other way for them to support different disconnected token types.  The specification was intended to be token independent and the assumption was always that the clients would also be.

--Gareth

---

From: Greg Hudson <[email-masked]>
Date: Fri, 19 Aug 2011 10:11:10 -0400

On Fri, 2011-08-19 at 08:53 -0400, [email-masked] wrote:
> required to implement all of the options since there appears to be no
> other way for them to support different disconnected token types.  The
> specification was intended to be token independent and the assumption
> was always that the clients would also be.

I agree, at least at the general level and for disconnected tokens.
(Does nextOTP make any sense for disconnected tokens?)

As for testing: you can unit-test client code using faked-up KDC
responses without a real token of the given type.  With only unit tests
there's always a risk that you will verify the wrong thing (i.e. not the
behavior you need to get a new token type working), but I think that
risk is acceptable in this case.

---

From: <[email-masked]>
Date: Fri, 19 Aug 2011 11:49:38 -0400

> I think you prompt the person to hit the next value button

Yes, that's the idea.  If the "nextOTP" flag is set then the client should prompt the user for the next value and use it in a second authentication request.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 19 Aug 2011 10:22:23 -0700

> I think you prompt the person to hit the next value button

Or else wait for the time to roll-over to the next.

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

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 19 Aug 2011 13:17:18 -0700

I don't believe any of my desirements justifies holding up publication.

Practically speaking, I'm most interested in the "disconnected" case.  It should also be the easiest to test thoroughly.  I also believe the draft is good enough for this case.  I would very much like to see client code capable of handling it widely deployed so I don't have to.

I would like to see some indication that the specification is sufficient for some realistic connected token, but I'm not sure I'm qualified to judge that.  I have not been looking at that case.  (Yubikey doesn't count.)

I would also like some better indication that the pin change stuff can work, but I expect pin changes to be "out of band" for anything I'm currently contemplating deploying.  If no one else volunteers, I can probably look at that again within the next few weeks.

> I'm thinking it would be useful to at least work out how a interoperable
> profile of one OTP mechanism such as HOTP would work.  I have some
> cycles to work on such a profile, but I would need help (any takers?).

Glad to help.  No promises about speed of turnaround for my feedback, but please CC me at least.