Subject: Re: [Ietf-krb-wg] Question on draft-ietf-krb-wg-otp-preauth-14

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 02 Feb 2011 17:19:13 -0500

--On Monday, January 31, 2011 05:29:10 AM -0500 [email-masked] 
wrote:

>>
>> In some sections you used "separate-pin-required" and in some
>> sections you used "pin-required".  Not sure if those are
>> separate things?  Or just a typo.
>>
>
> The "pin-required" and "separate-pin-required" flags are different.  The
> "pin-required" flag is the one that tells the client that it needs to
> collect a PIN and the "separate-pin-required" flag is the proposed new
> one that tells the client that the collected PIN should be returned
> separately to the KDC and not used as part of the OTP value.  It has also
> been suggested that the "pin-required" flag be renamed "collected-pin".

I don't understand.

If the token is connected, the client knows whether it needs to collect a 
PIN for interacting with the token based on its interface with the token. 
There is no need for the KDC to get involved.  Of course, if the KDC wants 
a copy of the PIN, it can set separate-pin-required and have the client 
return the PIN, separately from the OTP value.

If the token is disconnected, then there are two cases:

1) If separate-pin-required is set, the client collects the OTP and PIN
   separately, and forwards them to the KDC separately.

2) If separate-pin-required is not set, the client collects a single
   string from the user, which presumably contains both OTP and PIN,
   and forwards it to the KDC.  The question of in what order things
   should be concatenated depends on the requirements of the verifier
   backend, and must be communicated to the user by his administrator.

So, what do we need pin-required for?  Its value is implied by the token 
interface for connected tokens, and by separate-pin-required for 
disconnected tokens.

> I agree, this is entirely possible and I didn't mean to imply that it
> wasn't. The text is badly worded, what I meant to say was that if the PIN
> is passed to a connected token to be used in the OTP generation then it
> cannot be separated from the OTP value as requested by the KDC and so the
> "separate-pin-required" flag cannot really by honoured.
>
> How about this wording?
>
>    If client collects a PIN for a connected device then its behavior
>    will depend on the type of device but if it needs to pass
>    the PIN to the token in the OTP value request then it is not possible
>    for the client to exclude the PIN
>    value from the OTP and so client MUST NOT return the PIN in the otp-pin
>    field of the PA-OTP-REQUEST.

No, I think you're missing Frank's point.  The separate-pin-required field 
means that the client must include a separate field containing only the 
PIN.  The _client_ should _never_ include a separately-collected PIN in the 
otp-value field -- that's always up to the user (for disconnected tokens) 
or the token.

> I am not sure about this but I suppose it depends on what we say this
> flag means.  I was thinking of it as meaning that the KDC is requesting
> that the PIN be returned separately and not included as part of the OTP
> value rather than it is just sent to it.  In the case of disconnected
> tokens we are saying that the PIN should be sent to it and not
> concatenated with the token value and I was trying to achieve the same
> with connected tokens since if the PIN is passed to a token then this
> will not be the case since some tokens will concatenate the PIN and OTP
> value themselves, others will use it as input into the hash algorithm etc.

I think you're focusing too much on "not included in the OTP value" and not 
enough on "send the PIN separately".  With a connected token, the client 
has no control over whether the PIN is included in the OTP value in some 
way, but that doesn't mean it cannot send the separate PIN.

> Actually, I meant that it should be PIN+OTP but I agree that this is not
> clear.  This could be clarified as follows:
>
>    If the token is not a
>    connected device and the "separate-pin-required" flag is not set then
>    the OTP value SHALL be generated by appending the PIN with the value
>    from the token entered by the user and, if the "separate-pin-required"
> flag    is not set, SHALL be the value from the token.

A client cannot possibly implement this requirement unless it always 
collects the PIN separately.  If we require clients to always collect the 
PIN separately, then we may as well also require them to always return it 
separately; there is no reason the client should ever be expected to 
concatenate a separately collected PIN and OTP.  But if clients are 
required to always collect the PIN separately, then we will confuse users 
who have been instructed to concatenate them and expect the system to work 
that way.  We'll also break a variety of scenarios in which the interface 
between the user and the Kerberos client doesn't allow for more than one 
"password", which currently work with existing OTP schemes.

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

---

From: <[email-masked]>
Date: Thu, 3 Feb 2011 12:30:20 -0500

> >> sections you used "pin-required".  Not sure if those are separate 
> >> things?  Or just a typo.
> >>
> >
> > The "pin-required" and "separate-pin-required" flags are 
> different.  
> > The "pin-required" flag is the one that tells the client 
> that it needs 
> > to collect a PIN and the "separate-pin-required" flag is 
> the proposed 
> > new one that tells the client that the collected PIN should be 
> > returned separately to the KDC and not used as part of the 
> OTP value.  
> > It has also been suggested that the "pin-required" flag be 
> renamed "collected-pin".
> 
> I don't understand.
> 
> If the token is connected, the client knows whether it needs 
> to collect a PIN for interacting with the token based on its 
> interface with the token. 
> There is no need for the KDC to get involved.  Of course, if 
> the KDC wants a copy of the PIN, it can set 
> separate-pin-required and have the client return the PIN, 
> separately from the OTP value.
> 
In many cases, this will be the case.  For many software tokens, the token library is configured using metadata that describes whether it is working in pin-less or pin-full mode and the token library will instruct the Kerbeors client whether a PIN is required. But this is not always the case.  Some hardware connected tokens simply return the token value which the Kerberos client will need to collect the PIN and combine the two.  For this sort of case, the only way the Kerberos client will know whether it needs to collect a PIN will be through configuration or if the KDC tells it.  

These flags would allow the KDC to tell the client whether or not it needs to collect the PIN in the connected token cases where the token doesn't care about the PIN or where the library cannot instruct the client whether a PIN is required or not. In most cases they will not be required but for some token types they would be useful.

> So, what do we need pin-required for?  Its value is implied 
> by the token interface for connected tokens, and by 
> separate-pin-required for disconnected tokens.
> 

I agree that for disconnected tokens that these flags are not absolutely required since the client could just have an "Enter OTP" type prompt and they were not originally in the draft but I was asked to add them so that the client could customise the UI as need be.  It would allow the client to display "Enter token code" or "Enter PIN and tokencode" as required.

> > wasn't. The text is badly worded, what I meant to say was 
> that if the 
> > PIN is passed to a connected token to be used in the OTP generation 
> > then it cannot be separated from the OTP value as requested 
> by the KDC 
> > and so the "separate-pin-required" flag cannot really by honoured.
> >
> > How about this wording?
> >
> No, I think you're missing Frank's point.  The 
> separate-pin-required field means that the client must 
> include a separate field containing only the PIN.  The 
> _client_ should _never_ include a separately-collected PIN in 
> the otp-value field -- that's always up to the user (for 
> disconnected tokens) or the token.
> 
> > flag means.  I was thinking of it as meaning that the KDC is 
> > requesting that the PIN be returned separately and not included as 
> > part of the OTP value rather than it is just sent to it.  
> In the case 
> > of disconnected tokens we are saying that the PIN should be 
> sent to it 
> > and not concatenated with the token value and I was trying 
> to achieve 
> > the same with connected tokens since if the PIN is passed 
> to a token 
> > then this will not be the case since some tokens will 
> concatenate the 
> > PIN and OTP value themselves, others will use it as input 
> into the hash algorithm etc.
> 
> I think you're focusing too much on "not included in the OTP 
> value" and not enough on "send the PIN separately".  With a 
> connected token, the client has no control over whether the 
> PIN is included in the OTP value in some way, but that 
> doesn't mean it cannot send the separate PIN.
> 
> 
The problem I had was that if the separate_pin_required flag is set in the disconnected token case then the client will include the PIN in the otp-pin field and the token value in the otp-value field.  It will not include the PIN+OTP in the otp-value field.  But in the connected token case if the if the flag is set and the token requires the PIN to be sent to it then the PIN will be in the otp-pin field and in the otp-value field combined with the token value.  The behaviour in the two cases will not be the same.  I was trying to keep things consistent but if this is acceptable them I am OK with defining things the way you and Frank describe.

> > Actually, I meant that it should be PIN+OTP but I agree 
> that this is 
> > not clear.  This could be clarified as follows:
> >
> >    If the token is not a
> A client cannot possibly implement this requirement unless it 
> always collects the PIN separately.  If we require clients to 
> always collect the PIN separately, then we may as well also 
> require them to always return it separately; there is no 
> reason the client should ever be expected to concatenate a 
> separately collected PIN and OTP.  But if clients are 
> required to always collect the PIN separately, then we will 
> confuse users who have been instructed to concatenate them 
> and expect the system to work that way.  We'll also break a 
> variety of scenarios in which the interface between the user 
> and the Kerberos client doesn't allow for more than one 
There was an error in the paragraph above, an extra "not" was in the text.
Hopefully this makes what I meant to say clearer.  

   If the client collects a PIN for a disconnected device 
   and the "separate-pin-required" flag
   is not set then the OTP value SHALL be generated by appending the PIN
   with the value from the token entered by the user and, if the
   "separate-pin-required" flag is set, it SHALL be the value from the
   token.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 03 Feb 2011 15:19:57 -0500

>  In many cases, this will be the case.  For many software tokens, the
>  token library is configured using metadata that describes whether it
>  is working in pin-less or pin-full mode and the token library will
>  instruct the Kerbeors client whether a PIN is required. But this is
>  not always the case.  Some hardware connected tokens simply return the
>  token value which the Kerberos client will need to collect the PIN and
>  combine the two.

Why would the client need to combine them?  Does it need to do something
with the combined result, other than send it to the KDC?  This sounds to
me like a disconnected token with a convenient way for handing off the
OTP.

> I agree that for disconnected tokens that these flags are not
>  absolutely required since the client could just have an "Enter OTP"
>  type prompt and they were not originally in the draft but I was asked
>  to add them so that the client could customise the UI as need be.  It
>  would allow the client to display "Enter token code" or "Enter PIN and
>  tokencode" as required.

OK, that makes sense.

> Hopefully this makes what I meant to say clearer.  

No, I hadn't even noticed that.  Actually, the problem was that I wasn't
reading carefully enough and thought we were talking about disconnected
devices.  For a connected device, it's still unclear to me why you'd
ever want the client to take two values and concatenate them together in
one field, instead of doing that on the server.

-- Jeff

---

From: <[email-masked]>
Date: Fri, 4 Feb 2011 06:22:01 -0500

> > > If the token is connected, the client knows whether it needs to 
> > > collect a PIN for interacting with the token based on its 
> interface 
> > > with the token.
> > > There is no need for the KDC to get involved.  Of course, 
> if the KDC 
> > > wants a copy of the PIN, it can set separate-pin-required 
> and have 
> > > the client return the PIN, separately from the OTP value.
> > > 
> 
> Why would the client need to combine them?  Does it need to 
> do something with the combined result, other than send it to 
> the KDC?  This sounds to me like a disconnected token with a 
> convenient way for handing off the OTP.
> 
> 
>
If the plain-text OTP is being sent to the KDC then the client does not need to do anything with the values and so could send them separately in which case the KDC would need to combine the values to generate the OTP value before calling the OTP server but would not be possible when hashed values are used.  In this case the client needs to combined PIN and token value to generate the OTP value so that it can be hashed and used to generate a key and the KDC needs to retrieve the same hashed values from the OTP server so that it can generate the same key.  

By having the client generate the OTP value in the same way in both cases, I was trying to treat it in the same way and not involve the KDC in the any details of OTP generation.  Apart from the case where the PIN needs to be sent to the KDC, it should be possible in the mode where the plain-text PIN is being sent for the client to send a single OTP value to the KDC regardless of token type.  For disconnected tokens and some connected tokens, the client would need to combine the PIN (if there is one) and the token value but for other connected tokens the OTP value will be returned by the token when passed the PIN.  

--Gareth

---

From: <[email-masked]>
Date: Mon, 7 Feb 2011 12:43:10 -0500

Following the recent discussion around PIN handling in the OTP pre-auth draft, here are the updated changes:

1) Add a new flag to OTPFlags of the PA-OTP-CHALLENGE (section 4.1)

-- separate-pin-required (6)

         If the "separate-pin-required" flag is set then the PIN
         collected by the client SHOULD NOT be used in the generation of
         the OTP value and SHOULD be returned in the otp-pin field of
         the PA-OTP-REQUEST.

2) Renamed flags in PA-OTP-CHALLENGE (section 4.1)

	Renamed "pin-required" to "collect-pin"
	Renamed "pin-not-required" "do-not-collect-pin"

3) Add the following to the PA-OTP-REQUEST (section 4.2)

		   otp-pin        [6]  OCTET STRING                OPTIONAL	

   otp-pin
      The OTP PIN value entered by the user.  This value MUST NOT be
      present unless the "separate-pin-required" flag was set in the PA-
      OTP-CHALLENGE.

4) New text for section 3.2:

   If the KDC requires the PIN of an OTP token to be returned to it
   separately then it SHOULD set the "separate-pin-required" flag in the
   otp-KeyInfo representing that token.

5) Updated text for section 3.3

Paragraph 5:

   If the "collect-pin" flag is set then the token requires a PIN to be
   collected by the client.  If the "do-not-collect-pin" flag is set in
   the otp-keyInfo from the PA-OTP-CHALLENGE, then the token represented
   by the otp-keyInfo does not require a PIN to be collected by the
   client as part of the OTP value.  If neither of the "collect-pin" nor
   "do-not-collect-pin" flags are set then PIN requirements of the token
   are unspecified.  If both flags are set then client SHALL regard the
   request as invalid.

   If the "separate-pin-required" flag is set then any PIN collected by
   the client MUST be included in the otp-pin of the PA-OTP-REQUEST.

Paragraph 6:

   If client collects a PIN for a connected device then its behavior and
   how the PIN is used to generate the OTP value will depend on the type
   of device.  If the client collects a PIN for a disconnected device
   and the "separate-pin-required" flag is not set then the OTP value
   SHALL be generated by appending the PIN with the value from the token
   entered by the user and, if the "separate-pin-required" flag is set,
   it SHALL be the value from the token.

6) Add new error code for the case where a PIN was not included in the PA-OTP-REQUEST but is required by the KDC.

Add new text at the end of paragraph 5 section 3.4

   In addition,
   the KDC MUST fail the authentication request with
   KDC_ERR_PIN_REQUIRED if it requires a separate PIN to the OTP value
   and an otp-pin was not included in the PA-OTP-REQUEST

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 07 Feb 2011 19:07:49 +0100

> Following the recent discussion around PIN handling in the OTP pre-auth draft, here are the updated changes:

The changes looks good to me.  It would be easier to review the final
document for internal consistency if we get a new draft submitted with
these changes in it.

Thanks,
/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 07 Feb 2011 18:22:58 -0500

> document for internal consistency if we get a new draft submitted with

+1

---

From: Frank Cusack <[email-masked]>
Date: Fri, 25 Feb 2011 10:58:59 -0800

>> document for internal consistency if we get a new draft submitted with

+1 (looks good, and would like to see the complete draft)
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg