Subject: [Ietf-krb-wg] AD review of draft-ietf-krb-wg-otp-preauth

From: Stephen Farrell <[email-masked]>
Date: Sun, 14 Aug 2011 17:58:20 +0100

Hi,

This is a well written document and the protocol looks fine. Good job,

I've a few questions/comments on this but there's nothing major that
needs fixing in the document, so these can be treated along with
whatever IETF LC comments are received. I've requested IETF LC for
this one.

Cheers,
S.

1) Why is there no MTI OTP scheme specified? I assume that's because
the most interesting OTP schemes are proprietary. If that's the case,
do we know if vendors intend to document any of their schemes? (I'm
just raising this in case the WG didn't consider it, and not asking
for any particular change.)

2) 1.1 - expanding the FAST acronym on 1st use would be better

3) 1.2 - the distinction between the 4 pass and 2 pass variants in the
1st paragraph isn't clear to me. It says that the 4-pass variant "can
only be used for users that require pre- authentication" but that the
2-pass variant "can be used in cases where the client can determine in
advance that OTP pre- authentication is supported by the KDC, which OTP
key should be used and the encryption parameters required by the KDC."
Those don't sound like distinct cases to me so maybe some rewording is
needed that might make it more obvious when to go for 4-pass and when
for 2-pass? (Note, I'm not saying the text is wrong, it just doesn't
clarify when each of the variants is suitable to use.) Maybe just move
the sentence starting "Note that this variant..." and it'd be clear. (It
looks like maybe that was added late, and its positioning causes the
confusion.)

4) Using two different symbols ("|" and "||") for catenation in the
same section seems a bit of a luxury:-)

5) Is there a need for a matching rule for otp-service and otp-vendor?
(I dunno.) If there is, are these supposed to be case sensitive or not
when ASCII values are used?

6) Are there any additional security considerations that might usefully
be added in the light of recent token compromises? (I couldn't think of
any, but maybe the WG will.)

7) The ASN.1 module imports from rfc 3280, says the comment, which is
wrong - latest one of those is in 5280. And I guess a normative
reference should be added for that too.

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

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 14 Aug 2011 21:48:01 +0200

> for any particular change.)

What is there for a particular OTP vendor to document?

If something is needed, I will help with necessary work to support
YubiKey/HOTP/TOTP in Kerberos.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Sun, 14 Aug 2011 16:08:45 -0400

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

    Stephen> 1) Why is there no MTI OTP scheme specified? I assume
    Stephen> that's because the most interesting OTP schemes are
    Stephen> proprietary. If that's the case, do we know if vendors
    Stephen> intend to document any of their schemes? (I'm just raising
    Stephen> this in case the WG didn't consider it, and not asking for
    Stephen> any particular change.)

We did have some discussion of MTI, but not quite in response to this
specific question.
I'd appreciate comments from the WG on this issue.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Sun, 14 Aug 2011 17:51:12 -0700

When this draft got started I was hoping for a non-proprietary MTI option.  However I'm happy  with the current result---nothing proprietary is necessary for a functional client implementation.  (That's the hard part to deploy, anyway.)  

If RSA gets some early-to-market advantage in exchange for the work it took to complete the RFC, I think that's a fair exchange.  There's nothing in the draft to prevent future competition, or another RFC defining how a specific (possibly non-RSA) OTP should work.

> I'd appreciate comments from the WG on this issue.

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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 15 Aug 2011 09:12:08 +0200

"Henry B. Hotz" <[email-masked]> writes:

> When this draft got started I was hoping for a non-proprietary MTI
> option.  However I'm happy with the current result---nothing
> proprietary is necessary for a functional client implementation.
> (That's the hard part to deploy, anyway.)
>
> If RSA gets some early-to-market advantage in exchange for the work it
> took to complete the RFC, I think that's a fair exchange.  There's
> nothing in the draft to prevent future competition, or another RFC
> defining how a specific (possibly non-RSA) OTP should work.

There is already running code for a non-RSA mechanism.  Why would
anything in addition to the current document be needed?  My impression
is that this is a document about generic OTP support in Kerberos, not
support for SecurID in Kerberos.

/Simon

---

From: <[email-masked]>
Date: Mon, 15 Aug 2011 08:21:55 -0400

> support for SecurID in Kerberos.

It was definitely the intent for this to be a generic OTP mechanism rather than being specific to a particular one.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Tue, 16 Aug 2011 10:27:53 -0400

> for any particular change.)

I think the WG consensus was that there was no need for a change here.

> 2) 1.1 - expanding the FAST acronym on 1st use would be better

Updated to:

   This document describes a Flexible Authentication Secure Tunneling
   (FAST) [RFC6113] factor that ...

> looks like maybe that was added late, and its positioning causes the

I have removed the text "Note that this variant can only be used for users that require pre-authentication" which I agree is potentially confusing.  The key point is that the 2-pass mode can be used when the client has the required configuration information.

> same section seems a bit of a luxury:-)

The original reason for the two was that "|" was intended to indicate binary concatenation and "||" was for string concatenation but in this case, the distinction is probably moot since it is only used when concatenating the Base64 encoding of a key and a string and so the issue around null terminators is probably not an issue.

I have changed the text to only use "|".

> when ASCII values are used?

I hadn't really thought about this, but since one likely use of these strings would be in PKCS#11 templates used for C_FindObjectsInit and since PKCS#11 is case-sensitive it might be safest to make these strings case-sensitive.

> any, but maybe the WG will.)

None that I am aware of.

> reference should be added for that too.

Fixed.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Aug 2011 15:53:08 +0100

Hi Gareth,

Thanks for those responses, couple of things inline below.

> I think the WG consensus was that there was no need for a change here.

Right. I did assume that. But I guess that each token device will
require someone to specify e.g. which options are supported and the
otp-vendor name string etc. Not a lot, but it has to be done somewhere.
At present, that seems to be left up to implementers to figure out,
with vendors, which may be just fine. I just wanted to call that out
in case it hadn't been noticed, or to find out if someone was planning
to write up token specific drafts or not. (I don't mind how the WG
want to handle that, but I suppose I ought have a preference for
it being done via IETF-stream or individual RFCs:-)

By the way - MTI = mandatory to implement (someone asked).

> I hadn't really thought about this, but since one likely use of these strings would be in PKCS#11 templates used for C_FindObjectsInit and since PKCS#11 is case-sensitive it might be safest to make…

Case sensitive is probably better all right (less I18N silliness:-).
Worth a check that the case is the same throughout the doc so, I
think there are a couple that might be better changed, and I guess
you should say that they're case sensitive.

>> reference should be added for that too.

Thanks,
S.

---

From: <[email-masked]>
Date: Tue, 16 Aug 2011 11:15:20 -0400

Stephen,

Thanks a lot for the quick response.

> By the way - MTI = mandatory to implement (someone asked).

I also had to ask someone what MTI meant :-)

I agree that it is likely that there will need to be OTP algorithm specific profiles of this document but I was not sure where the best place for this is or what the convention is.  For example, PKCS#11 Amendment 1 which lays out a framework for supporting connected OTP tokens in PKCS#11 contains descriptions of how SecurID, OATH HOTP and ActiveIdentity ACTI tokens.

> > I hadn't really thought about this, but since one likely use of these
> strings would be in PKCS#11 templates used for C_FindObjectsInit and
> since PKCS#11 is case-sensitive it might be safest to make these
> strings case-sensitive.
>

I agree that case sensitive is probably safest and will check the document

--Gareth

---

From: Sam Hartman <[email-masked]>
Date: Tue, 16 Aug 2011 15:39:40 -0400

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

    Stephen> Hi Gareth,

    Stephen> Thanks for those responses, couple of things inline below.

    Stephen> On 16/08/11 15:27, [email-masked] wrote:
    >>> the most interesting OTP schemes are proprietary. If that's the
    >>> case, do we know if vendors intend to document any of their
    >>> schemes? (I'm just raising this in case the WG didn't consider
    >>> it, and not asking for any particular change.)
    >> 

    Stephen> Right. I did assume that. But I guess that each token
    Stephen> device will require someone to specify e.g. which options
    Stephen> are supported and the otp-vendor name string etc. Not a
    Stephen> lot, but it has to be done somewhere.  At present, that
    Stephen> seems to be left up to implementers to figure out, with
    Stephen> vendors, which may be just fine. I just wanted to call that
    Stephen> out in case it hadn't been noticed, or to find out if
    Stephen> someone was planning to write up token specific drafts or
    Stephen> not. (I don't mind how the WG want to handle that, but I
    Stephen> suppose I ought have a preference for it being done via
    Stephen> IETF-stream or individual RFCs:-)

I'd hope we would not need any drafts for disconnected mode tokens.

How far could we get with a draft describing how to use PKCS11 with this
specification for connected mode tokens?

Regardless of what drafts are needed here, I don't think they need to
block this draft.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Aug 2011 22:59:19 +0100

On 08/16/2011 08:39 PM, Sam Hartman wrote:
...

> Regardless of what drafts are needed here, I don't think they need to

Agreed. I hadn't considered doing that myself.

I guess it might be no harm to be able to answer the question in case
someone else on the IESG asks.

As of now, my impression is that the WG's approach is that specs
for specific tokens are not currently planned partly since the most
important ones involve proprietary details, but that if someone
turns up with a token-specific spec the WG would consider it
(not necessarily adopt). And I'm fine with that.

So, is the above ok?

S.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 16 Aug 2011 19:13:59 -0400

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

    Stephen> As of now, my impression is that the WG's approach is that
    Stephen> specs for specific tokens are not currently planned partly
    Stephen> since the most important ones involve proprietary details,
    Stephen> but that if someone turns up with a token-specific spec the
    Stephen> WG would consider it (not necessarily adopt). And I'm fine
    Stephen> with that.

The above is fine.  I think it's also our impression that you probably
don't need specs for disconnected tokens and you might be able to get
reasonably far on the client without a spec for a connected token,
especially if you happen to only have one connected at a moment.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 17 Aug 2011 09:55:03 +0200

> especially if you happen to only have one connected at a moment.

I have a mild concern that the document does not explain what kind of
additional specifications would be required to get interoperability.  If
we believe additional documents could be required, there should be some
guidance on what such a document should cover.

Before this discussion, I didn't think any additional documentation
would be needed, but I now realize that a "profile" document for a OTP
vendor should cover at least:

* Structure of "otp-vendor", "otp-service", and "otp-tokenInfo" values
* Whether it is a connected or disconnected token (or some combination)
* Whether the system makes use of PIN expiration
* Whether the system makes use of PA-OTP-PIN-CHANGE messages
* Whether the system makes use of the nextOTP flag
* Whether the system allows the KDC to obtain future OTP values (i.e.,
  allow must-encrypt-nonce)
* Whether the system uses hashed OTPs
* Whether the token needs a challenge and how it works
* Whether the separate-pin-require flag use used or not

There may be more (or less).

I'm thinking it would be useful to at least work out how a interopable
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?).

I believe working on such a profile will reveal issues in the core
document.  However, I don't want to block the core document -- any bugs
discovered can be fixed later on.

/Simon

---

From: Linus Nordberg <[email-masked]>
Date: Wed, 17 Aug 2011 10:49:25 +0200

Simon Josefsson <[email-masked]> wrote
Wed, 17 Aug 2011 09:55:03 +0200:

| Before this discussion, I didn't think any additional documentation
| would be needed, but I now realize that a "profile" document for a OTP
| vendor should cover at least:
| 
| * Structure of "otp-vendor", "otp-service", and "otp-tokenInfo" values
| * Whether it is a connected or disconnected token (or some combination)
| * Whether the system makes use of PIN expiration
| * Whether the system makes use of PA-OTP-PIN-CHANGE messages
| * Whether the system makes use of the nextOTP flag
| * Whether the system allows the KDC to obtain future OTP values (i.e.,
|   allow must-encrypt-nonce)
| * Whether the system uses hashed OTPs
| * Whether the token needs a challenge and how it works
| * Whether the separate-pin-require flag use used or not
| 
| There may be more (or less).
| 
| I'm thinking it would be useful to at least work out how a interopable
| 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?).

My work on an OTP plugin would definitely benefit from such a thing (and
most probably also from the process of making one).  I'm in.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Aug 2011 10:08:03 -0400

Simon, I'd definitely like to see such a profile document, but I don't
really have cycles to work on it.

I'm still of the belief that we'd discover that with the exception of
matching on the right token, none of those are really needed.  I'd like
to be proven right, but if I'm wrong, the easiest way to find that out
would be to go right the document and discover why something is
needed. 
Although if you started assuming those were not needed and now think
they are, then I'm probably missing something: you've clearly been
thinking about this more than I have.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Aug 2011 10:15:02 -0400

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?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 18 Aug 2011 22:40:56 +0200

> only implements the facilities needed by one particular OTP token?

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

If I were implementing this, I would only implement what I need in order
to get the OTP token(s) I am testing with to work.  Implementing
untestable features is rarely a good idea.

The three variants you mention are relatively basic and easy to get
right, but there are several flags that depends on the OTP flavour which
would be challenging to implement without vendor-specific knowledge
(e.g., nextOTP).

/Simon

---

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:
    >> * 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.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

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:
> 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.

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: 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:
    >> 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
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

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.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

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.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

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.

---

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

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