Subject: Re: [Ietf-krb-wg] Sean Turner's Discuss on draft-ietf-krb-wg-otp-preauth-19: (with DISCUSS and COMMENT)

From: <[email-masked]>
Date: Fri, 7 Oct 2011 05:56:38 -0400

>
> #2) s4.2: Is the otp-vendor is this the same as the <Manufacturer>
> element from RFC 6030?  RFC 6030 came through the IESG and we had a
> (some might say lengthy) discussion about the <Manufacturer> field.
> There were concerns about where the values would come from.
> Originally, the authors of RFC 6030 wanted to take it from the OATH
> Manufacturer Prefix registry (http://www.openauthentication.org/oath-
> id/prefixes), but to get in that registry you have to pay, if I
> remember correctly, like $500.  Obviously, a free registry would have
> been better - and there is one: IANA's Enterprise Numbers.  So what
> ended up in the RFC was this:
>
>       This element indicates the manufacturer of the
>       device.  Values for the <Manufacturer> element MUST be taken from
>       either [OATHMAN] prefixes (i.e., the left column) or from the
> IANA
>       Private Enterprise Number Registry [IANAPENREG], using the
>       Organization value.  When the value is taken from [OATHMAN],
>       "oath."  MUST be prepended to the value (e.g., "oath.<prefix
> value
>       from [OATHMAN]>").  When the value is taken from [IANAPENREG],
>       "iana."  MUST be prepended to the value (e.g.,
> "iana.<Organization
>       value from [IANAPENREG]>").
>
> If the otp-vendor supposed to convey the same kind of info (or exactly
> the same kind of info) then I think it needs to use some similar
> language.
>

The otp-vendor does appear to play the same role as the <Manufacturer> in RFC6030. Its purpose is to assist the client in locating the correct OTP token in situations where the user may have multiple tokens from different vendors/manufacturers.

However, the main purpose of otp-vendor is to display to the user and so assist them in locating the token then need and so this field needs to be user friendly.  Maybe wording similar to that from RFC 6030 could be used but using the enterprise name rather than the OATH prefix and IANA number.

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

---

From: <[email-masked]>
Date: Fri, 7 Oct 2011 12:34:46 -0400

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> #3) RFC 6030 includes a CheckDigit field:
> 
>    This attribute indicates whether a device needs to
>    check the appended Luhn check digit, as defined in
>    [ISOIEC7812], contained in a challenge.  This is only valid if
>    the 'Encoding' attribute is set to 'DECIMAL'.  A value of TRUE
>    indicates that the device will check the appended Luhn check
>    digit in a provided challenge.  A value of FALSE indicates that
>    the device will not check the appended Luhn check digit in the
>    challenge.
> 
> Is such a field needed when the OTPFormat is Decimal?
> 

It looks as if this may be required but to cover the <ResponseFormat> case in RFC 6030 than the <ChallengeFormat>.  From what I understand, the <ResponseFormat> is intended to describe the output of the OTP token whether it is in response to a challenge or not and seems to be there mainly to support the optional checksum digit supported by HOTP [RFC4226].

If HOTP has this option then I would think that it needs to be added as an extra OTPFlag in the PA-OTP-CHALLENGE in section 4.1.

--Gareth

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Oct 2011 06:19:33 -0400

If we can say that vendor-id is either exactly matched against something
in a hardware/software token or is displayed to a user, I don't
understand why it needs to come from a registry.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sean Turner <[email-masked]>
Date: Mon, 10 Oct 2011 19:18:19 -0400

On 10/7/11 5:56 AM, [email-masked] wrote:
>>
>> #2) s4.2: Is the otp-vendor is this the same as the<Manufacturer>
>> (some might say lengthy) discussion about the<Manufacturer>  field.
>>        device.  Values for the<Manufacturer>  element MUST be taken from
> The otp-vendor does appear to play the same role as the<Manufacturer>  in RFC6030. Its purpose is to assist the client in locating the correct OTP token in situations where the user may have multiple tokens from different vendors/manufacturers.
>

In PSKC, the choice value after the prefix is either the two letter code 
for the company from that OATH registry or the enterprise name from the 
ESN registration:

Decimal
| Organization
| | Contact
| | | Email
| | | |
1
   NxNetworks
     Michael Kellen
       OID.Admin&NxNetworks.com

Note that a couple of the enterprise names appear in both registries.

spt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 12 Oct 2011 09:32:32 -0400

On Wed, 2011-10-12 at 09:07 -0400, Sean Turner wrote:
> On 10/11/11 6:19 AM, Sam Hartman wrote:
> Sam,
> In the client response when otp-vendor is included in the challenge, 
> there's clearly no need for them to come from a registry because they 
> client just copies the value from the challenge.  For the challenge and 
> the client response when there's no otp-vendor in the challenge, how 
> will we have a reasonable chance of getting KDCs and clients from 
> different companies to agree on values?

There are two possibiities:

1) It's displayed to the user, to help them find a token.  In this case,
   it doesn't need to be an exact match; it just needs to lead the user
   to the right place.

2) It's compared against an ID provided by the token.  In this case,
   neither the KDC nor the client gets a say -- the choice of ID is up
   to the token manufacturer, and out of scope for the IETF.

---

From: Sean Turner <[email-masked]>
Date: Wed, 12 Oct 2011 09:07:55 -0400

Sam,

spt

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Oct 2011 11:14:56 -0400

>>>>> "Sean" == Sean Turner <[email-masked]> writes:

    Sean> I'm going to clear this part of my discuss because there's a
    Sean> way out if the value supplied by the KDC and token don't
    Sean> match.  But, it does seem to me that if I build the KDC and
    Sean> you build the token and we don't consult a common list to
    Sean> populate the otp-vendor field that there's a chance the
    Sean> otp-vendor will often need to be presented to the client.

Actually, I think I now understand what's going on here a bit better.
For proprietary tokens, there's generally an assumption that the token
manufacturer is providing some code that runs in the KDC or that the KDC
calls out to.  For example there's plugin work going on that can either
load a token-specific plugin or call out to a web service on the KDC.
There, it would be bad if two people called their incompatible tokens
the same thing, but  that's fairly unlikely.

Then there is the case where we have some sort of standardized
algorithm--HOTP or the like.
In this case you need one of the following:

1) A document describing how to provision that algorithm with PKCS11,
Kerberos, or something.

or

2) people who deploy tokens to know what their tokens do. If I've bought
5000 tokens, I probably know what my tokens are going to claim as a
vendor ID and I can tell my KDC.  It's probably better if it's
standardized somewhere, but probably not a big deal if it isn't.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 12 Oct 2011 11:16:20 -0400

On Wed, 2011-10-12 at 10:45 -0400, Sean Turner wrote:

> I'm going to clear this part of my discuss because there's a way out if 
> the value supplied by the KDC and token don't match.  But, it does seem 
> to me that if I build the KDC and you build the token and we don't 
> consult a common list to populate the otp-vendor field that there's a 
> chance the otp-vendor will often need to be presented to the client.

What it boils down to is that we don't set standards for tokens and so
don't get to tell the token vendor what to do.  OTOH, it doesn't matter,
because this is not a protocol constant and, AFAIK, it won't appear in
KDC or client implementations.  Rather, it appears in the token and
presumably gets told to the KDC as part of provisioning (which, for
Kerberos, is mostly not standardized).

-- Jeff

---

From: Sean Turner <[email-masked]>
Date: Wed, 12 Oct 2011 10:45:29 -0400

>     it doesn't need to be an exact match; it just needs to lead the user

This bit makes sense:

For unconnected tokens, the otp-vendor can be displayed.
For connected tokens, the otp-vendor can be displayed if the client 
can't find a match.

>     to the token manufacturer, and out of scope for the IETF.

For connected tokens:

The KDC provides the otp-token value and the client's machine matches it 
to the token supplied value (automated matching).   If it matches great, 
but if not see #1.

spt

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Oct 2011 11:22:22 -0400

Sean> On 10/11/11 6:19 AM, Sam Hartman wrote:
    >> If we can say that vendor-id is either exactly matched against
    >> something in a hardware/software token or is displayed to a user,
    >> I don't understand why it needs to come from a registry.

    Sean> Sam,

    Sean> In the client response when otp-vendor is included in the
    Sean> challenge, there's clearly no need for them to come from a
    Sean> registry because they client just copies the value from the
    Sean> challenge.  For the challenge and the client response when
    Sean> there's no otp-vendor in the challenge, how will we have a
    Sean> reasonable chance of getting KDCs and clients from different
    Sean> companies to agree on values?

I think the rest of this is discussed already, but my assumption is that
if there is no OTP-Vendor in the challenge, it doesn't much matter
whether the client sends back an OTP-vendor or whether it's correct.
I.E. if a client happened to pick up some string from a plugin it
loaded, then that would be a fine thing to send.
The KDC SHOULD NOT reject a request that would have been accepted
without a vendor-id because it includes a vendor ID.
The KDC SHOULD NOT reject a request without a vendor ID unless it needs
to disambiguate bteween two tokens for an account.

---

From: <[email-masked]>
Date: Thu, 13 Oct 2011 11:04:19 -0400

> It looks as if this may be required but to cover the <ResponseFormat>
> case in RFC 6030 than the <ChallengeFormat>.  From what I understand,
> the <ResponseFormat> is intended to describe the output of the OTP
> token whether it is in response to a challenge or not and seems to be
> there mainly to support the optional checksum digit supported by HOTP
> [RFC4226].
> 
> If HOTP has this option then I would think that it needs to be added as
> an extra OTPFlag in the PA-OTP-CHALLENGE in section 4.1.
> 

I think that the following changes will be required:

1) New paragraph towards the end of section 3.2 "KDC Challenge"

   If the token is a connected device and the KDC requires that the OTPs
   generated by the token have a Luhn check digit appended, as defined
   in [ISOIEC7812], then it SHOULD set the "check-digit" flag.  This
   flag only applies if the format of the OTP is decimal and so the otp-
   format field, if present, MUST have the value of "decimal".

2) New paragraph in section 3.3 "Client Response"

   If the "check-digit" flag is set then any OTP values generated by the
   token MUST have a Luhn check digit appended [ISOIEC7812].  This flag
   only applies to tokens that are connected devices and so if the flag
   is set the then the Client MUST use a connected token.  In addition,
   this flag only applies to decimal OTP values and so the token used
   MUST token be capable of generating tokens of that format.  Therefore
   the Client MUST regard the request as invalid if otp-format is
   present and set to any value other than "decimal".

3) New "check-digit" flag to OTPFlags in section 4.1

             OTPFlags ::= KerberosFlags
             -- reserved(0),
             -- nextOTP(1),
             -- combine(2),
             -- collect-pin(3),
             -- do-not-collect-pin(4),
             -- must-encrypt-nonce (5),
             -- separate-pin-required (6),
             -- check-digit (7)

         If the "check-digit" flag controls whether or not the OTP
         values generated by the token need to include a Luhn check
         digit [ISOIEC7812].  If this flag is set then the token used
         MUST be a connected device and the OTP value MUST be decimal
         with a check digit appended.

--Gareth

---

From: Sam Hartman <[email-masked]>
Date: Fri, 14 Oct 2011 12:56:11 -0400

>>>>>   <[email-masked]> writes:

    >    If the token is a connected device and the KDC requires that
    > the OTPs generated by the token have a Luhn check digit appended,
    > as defined in [ISOIEC7812], then it SHOULD set the "check-digit"

Shouldn't that be MUST not SHOULD?

    >    If the "check-digit" flag is set then any OTP values generated
    > by the token MUST have a Luhn check digit appended [ISOIEC7812].
    > This flag only applies to tokens that are connected devices and so
    > if the flag is set the then the Client MUST use a connected token.
    > In addition, this flag only applies to decimal OTP values and so
    > the token used MUST token be capable of generating tokens of that
    > format.  Therefore the Client MUST regard the request as invalid
    > if otp-format is present and set to any value other than
    > "decimal".

Are there ever tokens that can be used connected or disconnected or
otherwise were the KDC cannot tell if the token will be connected?  If
so, we need to either say that the client ignores this flag for
disconnected tokens or point out that in such cases the KDC MUST include
multiple token infos.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Linus Nordberg <[email-masked]>
Date: Sun, 16 Oct 2011 01:22:13 +0200

Sam Hartman <[email-masked]> wrote
Fri, 14 Oct 2011 12:56:11 -0400:

|     > 2) New paragraph in section 3.3 "Client Response"
| 
|     >    If the "check-digit" flag is set then any OTP values generated
|     > by the token MUST have a Luhn check digit appended [ISOIEC7812].
|     > This flag only applies to tokens that are connected devices and so
|     > if the flag is set the then the Client MUST use a connected token.
|     > In addition, this flag only applies to decimal OTP values and so
|     > the token used MUST token be capable of generating tokens of that
|     > format.  Therefore the Client MUST regard the request as invalid
|     > if otp-format is present and set to any value other than
|     > "decimal".
| 
| 
| Are there ever tokens that can be used connected or disconnected or
| otherwise were the KDC cannot tell if the token will be connected?  If
| so, we need to either say that the client ignores this flag for
| disconnected tokens or point out that in such cases the KDC MUST include
| multiple token infos.

I'm not sure that this is what you're asking, but the Yubikey token can
operate in both connected and disconnected (emulating a keyboard) mode.
Since the token has two separate configurations, the same physical token
with the same physical identification can be used in both connected and
disconnected mode.  The user picks which of the two configurations to
use by pressing the key on the token for a longer or a shorter period of
time.

---

From: <[email-masked]>
Date: Mon, 17 Oct 2011 06:15:01 -0400

> use by pressing the key on the token for a longer or a shorter period

The SecurID SID800 can also be used in this way and I believe that there are disconnected tokens that apply checksums (Vasco Digipass?).   Since the client would have no control over these tokens, it seems as if the connected requirement is too strict and that, as Sam suggested, it would be more correct to allow the client to ignore the flag if the token is disconnected.

How about the following?

      If the "check-digit" flag is set then any OTP values
        SHOULD be decimal and have a Luhn check digit appended [ISOIEC7812].
      If the token is disconnected then the Client MAY ignore this flag
      but if the token is connected then the Client MUST enforce it.
      The Client MUST regard the request as invalid
      if otp-format is present and set to any value other than
      "decimal".

--Gareth

---

From: Sam Hartman <[email-masked]>
Date: Mon, 17 Oct 2011 07:21:45 -0400

The new text works for me.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Mon, 17 Oct 2011 07:58:10 -0400

> The new text works for me.

OK, the other changes need to be changed accordingly

   If the KDC requires that the OTPs
   generated by the token have a Luhn check digit appended, as defined
   in [ISOIEC7812], then it MUST set the "check-digit" flag.  This
   flag only applies if the format of the OTP is decimal and so the otp-
   format field, if present, MUST have the value of "decimal".

         If the "check-digit" flag controls whether or not the OTP
         values generated by the token need to include a Luhn check
         digit [ISOIEC7812].  If the token is disconnected then the
         Client MAY ignore this flag but if it is connected then
         the OTP MUST be decimal with a check digit appended.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg