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

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Jan 2011 22:37:19 +0100

I know that we have passed WGLC on this document, but this is more of a
implementation question than a WGLC comment.  There is a good chance
that I have just misunderstood something, so I'm looking for
clarification.

The document says:

   If client collects a PIN for a connected device then its behavior
   will depend on the type of device but it will generally need to pass
   the PIN to the token in the OTP value request.  If the token is not a
   connected device then the OTP value SHALL be generated by
   concatenating the PIN and the value from the token entered by the
   user.

I'm working with a token that supports different modes (HOTP and a
proprietary one) and it falls into the second category above.  To
implement two-factor mode the OTP will contain of two parts:

    [PIN/password][value-from-token]

In my environment, neither the PIN/password nor the value-from-token can
be assumed to have fixed length.  Incoming OTPs could look like:

    PASSWD755224       (password + HOTP 6-digits)
    471135328482     (numeric PIN + HOTP 8-digits)
    secretccccccccccccdkrkedgchtlfefghcekefhlif (password + YubiKey)

In my environment, the KDC cannot obtain the valid next OTP value -- the
KDC can merely call out to an external component to do OTP validation,
and another to do password validation.  I believe this is pretty common
for OTP setups.

Thus in the following paragraph in the document my environment would
fall in the second cateogry:

   If the KDC is able to obtain the OTP values for the token then the
   OTP value SHOULD be used in the key generation as described in
   Section 3.6 and so the KDC SHOULD set the "must-encrypt-nonce" flag
   in the otp-keyInfo.  If the KDC is unable to obtain the OTP values
   for the token then the "must-encrypt-nonce" flag MUST NOT be set.  If
   the flag is not set then the OTP value will be returned by the client
   in the otp-value field of the PA-OTP-REQUEST and so if returning of
   OTP values in this way does not conform to KDC policy then the KDC
   SHOULD NOT include the otp-keyInfo for that token in the PA-OTP-
   CHALLENGE.

Thus my KDC will receive the OTPs in the "otp-value" field.

Now to my question:

How do I know where the password ends and the OTP begins when parsing
this on the KDC?

Of course, I can iterate through the following possible parsings and try
each of them:

password = P value-from-token = ASSWD755224
password = PA value-from-token = SSWD755224
password = PAS value-from-token = SWD755224
password = PASS value-from-token = WD755224
password = PASSW value-from-token = D755224
password = PASSWD value-from-token = 755224
password = PASSWD7 value-from-token = 55224
password = PASSWD75 value-from-token = 5224
password = PASSWD755 value-from-token = 224
password = PASSWD7552 value-from-token = 24
password = PASSWD75522 value-from-token = 4

I fear that this will hit DoS prevention at the external components
relatively quickly, and it seems like a sub-optimal design.

I have an idea to fix this, but I would like to make sure I haven't
misunderstood something obvious before spending time on describing it.

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

---

From: <[email-masked]>
Date: Fri, 21 Jan 2011 17:33:14 -0500

Simon,

I think you are correct and there may be an issue here.  The current draft requires that for a non-connected token that any PIN value is concatenated with the OTP value before being sent to the KDC.  (A disconnected token in this sense is one that is not given the PIN value as part of the OTP calculation and so a software token that uses the PIN in this way would be "connected".)  This was based on the assumption (incorrect it seems) that the PIN-OTP combination would be sent to the OTP server for validation and that the server would know the lengths of the two parts.  It also has the advantage of not requiring the client to prompt for the two parts separately.

However, if the PIN or Password is not part of the OTP calculation and is never passed the to backend HOTP validation server but sent to a separate server then the KDC will need to be able to separate the two parts and, as you point out, it will not know the lengths.

What is your proposal for resolving this?  One potential solution may be for the KDC to include a "separator" character in the PA_OTP_CHALLENGE that the client would use to separate the two components.  This would require the client to prompt for the PIN/Password and OTP separately.

--Gareth

> 
> I know that we have passed WGLC on this document, but this is 
> more of a implementation question than a WGLC comment.  There 
> is a good chance that I have just misunderstood something, so 
> I'm looking for clarification.
> 
> The document says:
> 
> I'm working with a token that supports different modes (HOTP 
> and a proprietary one) and it falls into the second category 
> above.  To implement two-factor mode the OTP will contain of 
> two parts:
> 
> In my environment, neither the PIN/password nor the 
> value-from-token can be assumed to have fixed length.  
> Incoming OTPs could look like:
> 
> In my environment, the KDC cannot obtain the valid next OTP 
> value -- the KDC can merely call out to an external component 
> to do OTP validation, and another to do password validation.  
> I believe this is pretty common for OTP setups.
> 
> Thus in the following paragraph in the document my 
> environment would fall in the second cateogry:
> 
> How do I know where the password ends and the OTP begins when 
> parsing this on the KDC?
> 
> Of course, I can iterate through the following possible 
> parsings and try each of them:
> 
> password = P value-from-token = ASSWD755224 password = PA 
> value-from-token = SSWD755224 password = PAS value-from-token 
> = SWD755224 password = PASS value-from-token = WD755224 
> password = PASSW value-from-token = D755224 password = PASSWD 
> value-from-token = 755224 password = PASSWD7 value-from-token 
> = 55224 password = PASSWD75 value-from-token = 5224 password 
> = PASSWD755 value-from-token = 224 password = PASSWD7552 
> value-from-token = 24 password = PASSWD75522 value-from-token = 4
> 
> I fear that this will hit DoS prevention at the external 
> components relatively quickly, and it seems like a sub-optimal design.
> 
> I have an idea to fix this, but I would like to make sure I 
> haven't misunderstood something obvious before spending time 
> on describing it.
> 
> Thanks in advance,
> /Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 22 Jan 2011 23:22:40 +0100

<[email-masked]> writes:

> Simon,
>
> I think you are correct and there may be an issue here.

Darn. :-(

> The current draft requires that for a non-connected token that any PIN
> value is concatenated with the OTP value before being sent to the KDC.
> (A disconnected token in this sense is one that is not given the PIN
> value as part of the OTP calculation and so a software token that uses
> the PIN in this way would be "connected".)  This was based on the
> assumption (incorrect it seems) that the PIN-OTP combination would be
> sent to the OTP server for validation and that the server would know
> the lengths of the two parts.  It also has the advantage of not
> requiring the client to prompt for the two parts separately.
>
> However, if the PIN or Password is not part of the OTP calculation and
> is never passed the to backend HOTP validation server but sent to a
> separate server then the KDC will need to be able to separate the two
> parts and, as you point out, it will not know the lengths.

Even if the PIN/Password is part of the OTP calculation, it doesn't work
generally if the value-from-token length can vary -- unless, of course,
the OTP server also resorts to the algorithm I described.

> What is your proposal for resolving this?  One potential solution may
> be for the KDC to include a "separator" character in the
> PA_OTP_CHALLENGE that the client would use to separate the two
> components.  This would require the client to prompt for the
> PIN/Password and OTP separately.

My idea was that we add two new protocol elements:

1) a OTPFlags flag "must-provide-splitpos" in the otp-keyInfo from the
KDC to the client whether the 'otp-value-splitpos' (see below) needs to
be provided or not.

2) A new field 'otp-value-splitpos' which points into the offset of the
'otp-value' string where the password ends and the value-from-token
begins.

Implementation wise, if the 'must-provide-splitpos' is not set, clients
could behave in any way and ask for the PIN/Password and
value-from-token together, but if the bit is set, the client could ask
for them separately or use some other logic to know where the password
ends, and then specify the 'otp-value-splitpos'.

This makes primarily clients slightly more complex, but not by that much
in my opinion.  Thoughts?

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Wed, 26 Jan 2011 11:16:29 -0500

Hmm.  I wonder whether Simon's use case wouldn't be better handled using
encrypted challenge or some new plaintext password system separate form
the OTP spec.  Why is the OTP preauth getting involved of a password
that is not an OTP PIN and is not involved in OTP calculation at all?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Frank Cusack <[email-masked]>
Date: Wed, 26 Jan 2011 09:11:17 -0800

>> It also has the advantage of not

But the client really really should prompt separately.  The OTP entry
should be unmasked (1234) and the PIN entry should be masked (****).

> 'otp-value' string where the password ends and the value-from-token

Is it not possible to add a pin-value field in the response?  As long
as you're adding a new field anyway, make it a pin field.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 26 Jan 2011 19:51:54 +0100

> that is not an OTP PIN and is not involved in OTP calculation at all?

Because the typical use-case for OTP is two-factor authentication, and
if the OTP preauth document doesn't explain how to achieve two-factor
authentication, we don't get interop for the typical use-case.

That said, I do share a concern that otp-preauth becomes complex due to
PIN handling; there is even support for changing PINs in there.  I would
prefer to separate handling of OTP and PIN but I don't see how easily.
Also, the document is so long overdue (but still two years younger than
krb5starttls :-)) that I was reluctant to bring this up at all, but
implementation just became too painful.  I would prefer a quick fix and
get this shipped.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 26 Jan 2011 19:59:57 +0100

> should be unmasked (1234) and the PIN entry should be masked (****).

People seems to disagree about this, and there is sadly too few user
interface experts participating here that I believe we should leave this
aspect to implementers.

> as you're adding a new field anyway, make it a pin field.

Sometimes the client doesn't know how to split up PIN and OTP, and if
the KDC doesn't require PIN and OTP to be separate, having separate
otp-value and pin-value fields require clients to do separate prompts.
I think that should be avoided if possible.

One possible improvements would be for the client to be permitted to
return otp-value-splitpos=0 if it couldn't separate PIN from OTP, even
when must-provide-splitpos is set, and let the KDC judge what to do in
that situation.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Wed, 26 Jan 2011 14:05:23 -0500

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

    Simon> Sam Hartman <[email-masked]> writes:
    >> Hmm.  I wonder whether Simon's use case wouldn't be better
    >> handled using encrypted challenge or some new plaintext password
    >> system separate form the OTP spec.  Why is the OTP preauth
    >> getting involved of a password that is not an OTP PIN and is not
    >> involved in OTP calculation at all?

    Simon> Because the typical use-case for OTP is two-factor
    Simon> authentication, and if the OTP preauth document doesn't
    Simon> explain how to achieve two-factor authentication, we don't
    Simon> get interop for the typical use-case.

I thought we got that through a PIN that is combined with the OTP token
somehow.  I feel very uncomfortable about this.  However, I agree done
is better than not done.  My advice would be to find a fix that is
maximally seperable from the rest of the spec so that if we find it is
wrong we can do something else later.
I'm not going to actually have any ideas on what the fix is.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Frank Cusack <[email-masked]>
Date: Wed, 26 Jan 2011 11:09:05 -0800

> interface experts participating here that I believe we should leave this

It can only be left to implementers if in fact the protocol allows for
separate PIN entry.

> I think that should be avoided if possible.

The otp-value field can contain the PIN if the client doesn't know
how to prompt separately.  In that case the KDC has to know how to
take the PIN and OTP apart.

> when must-provide-splitpos is set, and let the KDC judge what to do in

If the client doesn't know how to prompt separately, it also doesn't
know where the split position is.

-frank

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 26 Jan 2011 19:11:33 +0000

> I think that should be avoided if possible.

and just making one of the values OPTIONAL and have the client/kdc deal with splitting non splitting.

I feel that having opt-value-splitpos seems like gross hack, but then I don't understand the whole issue.

Love

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 26 Jan 2011 20:37:59 +0100

> It can only be left to implementers if in fact the protocol allows for

Right, that's my point -- both variants should be permitted.

> take the PIN and OTP apart.

That's true, so it could be solved like that too.

> know where the split position is.

That's not necessarily the case, the client may prompt for a combined
PIN+OTP and it could know the OTP length and would then be able to work
how long the PIN is from that.

/Simon

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 26 Jan 2011 12:43:45 -0800

I confess I haven't worried about PIN change before.  It might be handled externally for a given deployment.

Would it be reasonable to suggest PIN change be split into a separate document?  I'd rather not hold up the basic pre-auth mechanism while we hash out PIN change.  I could see PIN change being as fairly complex.  

Just to throw out possibilities:  Should PIN change just be a section in a new password change document?

> how long the PIN is from that.

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

---

From: Frank Cusack <[email-masked]>
Date: Wed, 26 Jan 2011 13:33:32 -0800

> Right, that's my point -- both variants should be permitted.

Agreed.  Sorry if I implied that it should ONLY be separate prompts.
Definitely a UI thing that the protocol shouldn't favor one way or
the other.

...
> how long the PIN is from that.

How would the client know the OTP length?  The only way is for the KDC
to tell it.  In that case the server doesn't even need to inform the
client of the length since it will simply know it when the PIN+OTP
is returned.  Unless I'm missing something here, which is very possible.

The only advantage I can see of the KDC informing the client of the
PIN and/or OTP length is so that the client can do a little bit of
extra validation before returning the user input to the KDC.

If there is a case where the KDC doesn't know the PIN length in a
combined PIN+OTP, and depends on the client to inform it of the
split position, then that client would have to be aware of the
difference between PIN and OTP and can just send it as separate
pieces of data (regardless of how the UI works).

There is an advantage if the KDC can inform the client if it expects
a PIN.  That gives the client a hint that it can prompt separately
if so desired.  But the length of the PIN seems like extra, non-useful
info and it may be unavailable to the KDC anyway and could even be
variable length (user could have multiple PINs, say normal and duress,
which are different lengths).
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 26 Jan 2011 13:47:06 -0800

> is returned.  Unless I'm missing something here, which is very possible.

IIUC RSA soft tokens (may?) have a different length from the hardware tokens.  Split point may vary per-user, not merely per deployment.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 Jan 2011 11:41:01 +0100

Frank Cusack <[email-masked]> writes:

> to tell it.

It is possible for the client to know the OTP length -- a simple way is
to query for PIN and OTP separetely, then it see the lengths.  Another
approach is when the client could have generated the OTP itself and
queried the user for a PIN (typical when you have OATH HOTP/TOTP
software running on a cell phone).  A third approach is when the client
could be aware of what kind of OTP algorithm is used (due to
environmental reasons or configuration), and infer the OTP length.

> which are different lengths).

Indeed -- the KDC generally doesn't know the length of the OTP, and
doesn't always need to know it.  However, if the KDC needs to know the
OTP length to be able to split up the information it receives and send
the PIN/OTP to different validation entitites, it has to get this
information from somewhere.  My proposal was that the KDC could flag
this situation, and request that the client attempts to help the KDC.  A
client that queries for the PIN and OTP separately would have no problem
providing this information.

/Simon

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 10:17:29 -0500

> 1) a OTPFlags flag "must-provide-splitpos" in the otp-keyInfo 
> from the KDC to the client whether the 'otp-value-splitpos' 
> (see below) needs to be provided or not.
> 
> 2) A new field 'otp-value-splitpos' which points into the 
> offset of the 'otp-value' string where the password ends and 
> the value-from-token begins.
> 
> Implementation wise, if the 'must-provide-splitpos' is not 
> set, clients could behave in any way and ask for the 
> PIN/Password and value-from-token together, but if the bit is 
> set, the client could ask for them separately or use some 
> other logic to know where the password ends, and then specify 
> the 'otp-value-splitpos'.
> 
> This makes primarily clients slightly more complex, but not 
> by that much in my opinion.  Thoughts?
> 
> /Simon
> 

The issue seems to only apply when the client collects the PIN in which case it can know the PIN length if it collects it separately.  If the token is a pinpad type where the client does not collect the PIN but the token folds it into the OTP value then the PIN is of no significance to the client or KDC.  

In the current draft, if the pin-required flag is set then this instructs the client that it needs to collect a PIN.  The only issue is that for HOTP type cases, the client MUST collect the PIN separately than the OTP in order for it to know its length since in many cases, the client would have a single prompt for both the PIN and OTP value.

I agree that your proposal would probably be the simplest way of achieving this.  My only suggestion is that the names of the elements be changed to make their purpose a bit clearer.

1) Add a new value for OTPFlags "pin-length-required"

-- pin-length-required (6)

2) Add a new value to PA-OTP-REQUEST of

otp-PINLen  [13] Int32  OPTIONAL

As you described, the pin-length-required flag would only be set if the pin-required flag is also set and would instruct the client that it must not only collect the PIN but must collect it in such a way that it can determine the length.  This effectively means that it will need to prompt for it separately.

This would require the text in section 3.3 to be updated:

   If the "pin-required" flag is set then the token requires a PIN to be
   collected by the client.  If the "pin-length-required" flag is also
   set then the length of the collected PIN is required and MUST be included 
   in the otp-PINLen of the PA-OTP-REQUEST.  If the "pin-required" flag is
   not set then the "pin-length-required" flag is of no significance and 
   SHOULD be ignored by the client.

   If the "pin-not-required" 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 "pin-required" nor "pin-not-required" flags are set 
   then PIN requirements of the token are unspecified.  If both flags are set
   then client SHALL regard the request as invalid.  

--Gareth

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 10:35:30 -0500

> >> PIN+OTP and it could know the OTP length and would then be able to 
> >> PIN+work
> > client of the length since it will simply know it when the 
> PIN+OTP is 
> > returned.  Unless I'm missing something here, which is very 
> possible.
> 
> 
I don't think the client needs to know the OTP length since for the KDC to split the PIN+OTP value, the length of the PIN is sufficient.

For this to work, the KDC needs a way to not only instruct the client that it needs to collect a PIN (the "pin-required") flag but that it must prompt for it separately and return the length. This could be achieved using Simon's proposal with a "pin-length-required" type flag.

If the flag is not set then the client can collect a combined PIN+OTP but if the flag is set then it will need to prompt for PIN and OTP separately so that it can determine the length.

--Gareth

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 Jan 2011 16:39:55 +0100

<[email-masked]> writes:

> I agree that your proposal would probably be the simplest way of
> achieving this.  My only suggestion is that the names of the elements
> be changed to make their purpose a bit clearer.

Good idea.

> otp-PINLen  [13] Int32  OPTIONAL

Negative values are not useful, so this should be UInt32.

> As you described, the pin-length-required flag would only be set if
> the pin-required flag is also set and would instruct the client that
> it must not only collect the PIN but must collect it in such a way
> that it can determine the length.  This effectively means that it will
> need to prompt for it separately.

There could be other approaches, so text in the document should be
flexible on this point -- but as far as I can tell, it already is, even
with your proposed change.

>    then client SHALL regard the request as invalid.  

I like it.

How about a small addition to explain semantics for otp-PINLen=0:

   The client MAY return a otp-PINLen of 0 if it is unable to collect
   the OTP in a way that the length of the PIN is known.  In this
   situation, the KDC will determine if it can resolve the request even
   without PIN length or else it will return a KRB-ERROR of type
   KDC_ERR_PIN_REQUIRED.

And add the new error code to the IANA section.

Thanks,
/Simon

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 10:44:00 -0500

> Negative values are not useful, so this should be UInt32.
Good point

> There could be other approaches, so text in the document 
> should be flexible on this point -- but as far as I can tell, 
> it already is, even with your proposed change.
> 

Wouldn't an OTP-PINLen of zero be valid if the token doesn't have a PIN?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 Jan 2011 16:51:51 +0100

> Wouldn't an OTP-PINLen of zero be valid if the token doesn't have a PIN?

Is that permitted when the KDC asserted the 'pin-required' bit?

/Simon

---

From: Frank Cusack <[email-masked]>
Date: Thu, 27 Jan 2011 09:13:03 -0800

On 1/27/11 10:17 AM -0500 [email-masked] wrote:
> In the current draft, if the pin-required flag is set then this instructs
> the client that it needs to collect a PIN.  The only issue is that for
> HOTP type cases, the client MUST collect the PIN separately than the OTP
> in order for it to know its length since in many cases, the client would
> have a single prompt for both the PIN and OTP value.

I disagree.  My own HOTP server implementation can take apart the PIN
and HOTP without any explicit information about the PIN length, on
a user-by-user basis and in all cases (even if the user has multiple
tokens with different HOTP lengths).

> As you described, the pin-length-required flag would only be set if the
> pin-required flag is also set and would instruct the client that it must
> not only collect the PIN but must collect it in such a way that it can
> determine the length.  This effectively means that it will need to prompt
> for it separately.

If the client is signaled that it must collect the PIN separately, it
can send the PIN data separately.  Collecting it separately, combining
the data and sending the split info, then requiring the KDC to take
apart the data, seems somewhat less good than just sending the data
separately.  pin-required is enough info for the client to know that
it should prompt separately; the length-required flag doesn't add
anything.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 12:09:41 -0500

> Is that permitted when the KDC asserted the 'pin-required' bit?

That flag is really telling the client that it needs to collect the PIN and so would not be set in the case of pin-less tokens but would be set if pin-full tokens are used where the token does not collect the PIN itself.  So if an otp-PINLen of zero was returned then an empty PIN was collected rather than the client was unable to collect it.  

I could imagine that such a situation could be valid in situations where users have passwords but one user set their password to an empty string.  

--Gareth

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 12:24:53 -0500

> > In the current draft, if the pin-required flag is set then this 
> > instructs the client that it needs to collect a PIN.  The 
> only issue 
> > is that for HOTP type cases, the client MUST collect the PIN 
> > separately than the OTP in order for it to know its length since in 
> > many cases, the client would have a single prompt for both 
> the PIN and OTP value.
> 
> I disagree.  My own HOTP server implementation can take apart 
> the PIN and HOTP without any explicit information about the 
> PIN length, on a user-by-user basis and in all cases (even if 
> the user has multiple tokens with different HOTP lengths).
> 

Sorry, I meant the HOTP case described by Simon where the KDC cannot split the values.

> If the client is signaled that it must collect the PIN 
> separately, it can send the PIN data separately.  Collecting 
> it separately, combining the data and sending the split info, 
> then requiring the KDC to take apart the data, seems somewhat 
> less good than just sending the data separately.  
> pin-required is enough info for the client to know that it 
> should prompt separately; the length-required flag doesn't 
> add anything.
> 
> 

I have no problem with having an otp-PIN value instead of the otp-PINLen.

--Gareth

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 Jan 2011 19:01:25 +0100

<[email-masked]> writes:

> That flag is really telling the client that it needs to collect the
> PIN and so would not be set in the case of pin-less tokens but would
> be set if pin-full tokens are used where the token does not collect
> the PIN itself.  So if an otp-PINLen of zero was returned then an
> empty PIN was collected rather than the client was unable to collect
> it.
>
> I could imagine that such a situation could be valid in situations
> where users have passwords but one user set their password to an empty
> string.

Ok.  I'm not sure I follow the pin-less token vs pin-full token
separation (in my world the pin is orthogonal to the token) but I don't
feel strongly about permitting clients to refuse here.  I was thinking
it would be useful in environments where the client simply cannot have
two prompts, and rather than giving up it could send what it can get to
the KDC and let it decide.

/Simon

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 13:21:10 -0500

> >> >>    situation, the KDC will determine if it can resolve 
> the request 
> >> >> even
> Ok.  I'm not sure I follow the pin-less token vs pin-full 
> token separation (in my world the pin is orthogonal to the 
> token) but I don't feel strongly about permitting clients to 
> refuse here.  I was thinking it would be useful in 
> environments where the client simply cannot have two prompts, 
> and rather than giving up it could send what it can get to 

I agree that that would be useful, my only issue was with using otp-pinLen of zero to indicate that.

One alternative would be that if the client cannot do the separate prompts, it simply doesn't include the otp-pinLen or otp-PIN element.  This would then allow the client to distinguish between a zero length PIN and not returning a PIN.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 Jan 2011 22:14:19 +0100

<[email-masked]> writes:

> One alternative would be that if the client cannot do the separate
> prompts, it simply doesn't include the otp-pinLen or otp-PIN element.
> This would then allow the client to distinguish between a zero length
> PIN and not returning a PIN.

I like that approach.

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 27 Jan 2011 17:20:33 -0500

> don't understand the whole issue.

I agree, it seems like a hack.

The issue is actually fairly straightforward.  The document contemplates 
two kinds of tokens -- "connected" tokens where the client communicates 
with the token directly or uses the value entered by the user as part of 
some computation to determine what to send to the KDC, and "disconnected" 
tokens where the token provides some value which is entered by the user and 
forwarded to the KDC.  The rest of this is only about the latter case.

One common usage model for disconnected tokens is for the user to type in 
his PIN immediately followed by the value provided by the token, as a 
single string.  Splitting that string back into a PIN and token value 
requires knowing the length of one of those.  For tokens where this model 
is common, that's not hard -- the entity doing the verification has a PIN 
database, and so knows exactly what the PIN is, or knows how long the OTP 
value is supposed to be, or both.  RSA SecurID tokens work this way. 
Unfortunately, this is the only model contemplated by the current draft, so 
only one protocol field is provided for the combined string.

The difficulty is that while this is an interface users may expect to see, 
it is not the _only_ UI -- they may expect to enter PIN and OTP separately. 
And, it's also not the only model KDC's and token verifiers may be expected 
to support; it may be necessary to provide the PIN and OTP separately to 
the backend, or even to separate backends (perhaps the PIN is in the KDB, 
but the OTP is verified by an external box).

So, the client must know whether to prompt for one value or two.  The 
client has no way to discover the type or requirements of a disconnected 
token, so this information must come from the KDC.  Separately, the client 
must know whether to _forward_ one value or two.  Finally, a single 
combined value is entered, then someone (client, KDC, or OTP verifier) must 
know how to separate them.

I would point out that in the case of a disconnected token, the client 
doesn't actually _do_ anything with the entered PIN and OTP value other 
than forward them to the KDC.  Therefore, I would suggest the following:

- The KDC provides a flag indicating whether the client should prompt
  for one value (PIN+OTP) or two values (PIN, OTP).  For generality,
  we may also wish to separately include OTP+PIN as an option, so that
  the client can adjust its prompts accordingly.

- The protocol provides two fields, with one of them optional, and the
  client is expected to always send back the number of values the KDC
  told it to prompt for -- anything else is an error.

- If the user is expected to enter two values, but the KDC needs a
  combined value, then it is the KDC's problem to concatenate the two
  values after it gets them from the client.

- If the user is expected to enter a combined value, then the KDC or
  whatever verifier service it uses must know how to do something useful
  with a combined value.  What it does and how is an implementation issue.
  The protocol rule is simple -- if you can't handle a combined string,
  don't ask for one!

The question of whether clients should enter one value or two is not up to 
us; the token systems we are talking about and the sites that use them 
already have usage models which the protocol must support.  Similarly for 
the question of whether input of these values should be clear, masked, or 
blind.

-- Jeff

---

From: Frank Cusack <[email-masked]>
Date: Thu, 27 Jan 2011 16:06:31 -0800

On 1/27/11 5:20 PM -0500 Jeffrey Hutzelman wrote:
> The
> token, so this information must come from the KDC.

The client could know this via manual configuration.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Fri, 28 Jan 2011 12:00:19 -0500

I have tried to summarise the changes required to support the separate PIN issue.  

- Add a new "separate-pin-required" flag which if set, instructs the client that the PIN should be returned to the KDC

- Add an otp-pin of the PA-OTP-REQUEST for returning the PIN

-- Add a new KDC_ERR_PIN_REQUIRED for the case where the KDC requires the PIN but didn't get it.

I have tried to cover the following use cases:

1) KDC requires combined PIN + OTP in plain text
    "separate-pin-required" not set in PA-OTP-CHALLENGE
    "must-encrypt-nonce" not set in PA-OTP-CHALLENGE
    PIN+OTP returned in otp-value of PA-OTP-REQUEST

2) KDC requires separate PIN and OTP in plain text
    "separate-pin-required" set in PA-OTP-CHALLENGE
    "must-encrypt-nonce" not set in PA-OTP-CHALLENGE
    OTP returned in otp-value of PA-OTP-REQUEST
    PIN returned in otp-pin of PA-OTP-REQUEST

3) KDC requires the combined OTP and PIN are used in key generation 
    "separate-pin-required" not set in PA-OTP-CHALLENGE
    "must-encrypt-nonce" set in PA-OTP-CHALLENGE
    otp-value not included in PA-OTP-REQUEST
    otp-pin not included in PA-OTP-REQUEST

4) KDC requires the PIN to be returned in plain text and OTP used in key generation
    "separate-pin-required" set in PA-OTP-CHALLENGE
    "must-encrypt-nonce" set in PA-OTP-CHALLENGE
    otp-value not included in PA-OTP-REQUEST
    PIN returned in otp-pin of PA-OTP-REQUEST

As Jeff pointed out, when "disconnected" tokens are used, the client is in control and can prompt as required and collect separate OTP and PIN values but with "connected" tokens, the client does not have control over how the OTP is generated using the PIN since it will generally need to pass the PIN to the token when requesting the OTP value.  Therefore, if the PIN is used the generation of the OTP in this way, the client cannot obey the "separate-pin-required" flag and so should not return the PIN in the otp-pin field. 

To support this, the main changes to the document would be as follows:

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

3) The text in section 3.3 would need to be updated:

   Paragraph 5:

   If the "pin-required" flag is set then the token requires a PIN to be
   collected by the client.  If the "separate-pin-required" flag is set
   then the KDC requires the PIN to be returned in the PA-OTP-REQUEST
   and so the PIN SHOULD NOT be used to generate the OTP value and any PIN 
   collected by the client MUST be included in the otp-pin 
   of the PA-OTP-REQUEST unless the client is unable to exclude the PIN
   from the OTP generation. If the "pin-required" flag is not set then the 
   "separate-pin-required" flag is of no significance and SHOULD be ignored 
   by the client.

  Paragraph 6:

   If client collects a PIN for a connected device then its behavior
   will depend on the type of device but it will generally need to pass
   the PIN to the token in the OTP value request.  Therefore, for 
   connected tokens, 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. 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 concatenating the PIN and 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.

4) 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 to section 3.4

   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: Sam Hartman <[email-masked]>
Date: Fri, 28 Jan 2011 13:04:37 -0500

>>>>> "Frank" == Frank Cusack <[email-masked]> writes:

    Frank> On 1/27/11 5:20 PM -0500 Jeffrey Hutzelman wrote:
    >> The client has no way to discover the type or requirements of a
    >> disconnected token, so this information must come from the KDC.

    Frank> The client could know this via manual configuration.

I don't think it is reasonable or desirable for this to be manually
configured.  One of the major advantages of disconnected tokens is that
you can use them on a client with no special software or configuration
on the client.  So, I strongly encourage the WG to maintain this
advantage.

As a consequence I think it is important that we minimize the number of
options in the disconnected case to exactly what's needed and make sure
that clients are required to implement all options.  Jeff made
compelling arguments about why the options he proposed are actually
needed.  I feel much more comfortable solving this problem after reading
Jeff's message.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 28 Jan 2011 19:12:21 +0100

> I have tried to summarise the changes required to support the separate

Thank you -- this looks splendid to me.

/Simon

---

From: Frank Cusack <[email-masked]>
Date: Fri, 28 Jan 2011 11:14:04 -0800

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.

More inline.

On 1/28/11 12:00 PM -0500 [email-masked] wrote:
>    the PIN to the token in the OTP value request.

I'm not crazy about the comment on how the technology is expected to work,
as it would push developers to ignore or exclude other possibilities.

>  Therefore, for
>    field of the PA-OTP-REQUEST.

Here, you've gone a step further, too far IMHO.  It *is* possible for a
connected token to not require a PIN at all, and for online verification
of the PIN.  By saying "MUST NOT" you are excluding this possibility.

The "separate-pin-required" flag should indicate to the client only that
the PIN must be sent separately to the KDC.  It should not be any
indication of how the client is supposed to interact with the token.

> If the token is not a
>    the OTP value SHALL be generated by concatenating the PIN and 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.

I like that this section does not state the order of the elements (pin+otp
vs otp+pin).  However that could lead to interop problems.  So there should
be some clarification.  I prefer something along the lines of
site-specific usage configuration.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Mon, 31 Jan 2011 05:29:10 -0500

> 
> 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'm not crazy about the comment on how the technology is 
> expected to work, as it would push developers to ignore or 
> exclude other possibilities.
> 
> >  Therefore, for
> Here, you've gone a step further, too far IMHO.  It *is* 
> possible for a connected token to not require a PIN at all, 
> and for online verification of the PIN.  By saying "MUST NOT" 
> you are excluding this possibility.
> 
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. 

> The "separate-pin-required" flag should indicate to the 
> client only that the PIN must be sent separately to the KDC.  
> It should not be any indication of how the client is supposed 
> to interact with 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 like that this section does not state the order of the 
> elements (pin+otp vs otp+pin).  However that could lead to 
> interop problems.  So there should be some clarification.  I 
> prefer something along the lines of site-specific usage configuration.
> 
> 
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.

Can you suggest some text for a more flexible system? 
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg