Subject: [Ietf-krb-wg] Internationalization and draft-ietf-krb-wg-otp-preauth

From: Sam Hartman <[email-masked]>
Date: Mon, 14 Nov 2011 04:00:48 -0500

Hi.  Stephen and I had a chat with the applications ADs regarding
internationalization.

First, I proposed using saslprep on the grounds that we have it today
and that while it's by no means perfect, we'll be in the same boat as
SCRAM, SASL plain and a number of other specs with regard to moving to a
new method for international comparison.

The ADs would like us to use something better.  They may be able to come
up with a proposal; if they cannot by tomorrow then we can move forward
with saslprep if we choose.

I want to confirm that we'd prefer to publish this draft now than to
wait for another solution to come along if it means waiting for more
than a few days.

Secondly, there is the issue of false positives in passwords.  The
approach we're taking maps a lot of strings together and is insensitive
to normalization and some other mappings. I think for example that
half-width spaces are mapped to normal ASCII spaces. So, if a user tries
to use some sort of funky Unicode space to make their PIN "stronger," it
may not work.

I view this as choosing usability over character set tricks. We don't
want to depend on a user being able to reliably enter some funky space
character on any keyboard they might use. Nor do we want to depend on a
keyboard not generating an unexpected space character.

The ADs are fine with that, but they ask us to add security
considerations text.
(Also, if people in the WG disagree with this approach, please speak
up.)

I propose adding the following text to section 6.5:

If PINs contain international characters, similar looking or similar
functioning characters may be mapped together. For example, the combined
and decomposed forms of accented characters will typically be treated
the same. Users who attempt to exploit artifacts of international
characters to improve the strength of their PINs may experience false
positives in the sense that PINs they intended to be distinct are not
actually distinct. This decision was made in order to improve usability
across the widest variety of input methods. Users can choose other
methods to add strength to PINs.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 14 Nov 2011 11:39:10 +0100

> wait for another solution to come along if it means waiting for more

I support publishing sooner rather than later.

"Using saslprep" is a bit under-specified though.  Is there a concrete
patch to the document to consider?  I'm concerned that 1) the text may
not be complete enough to permit interop (for example, it is common to
forget to mention which mode of saslprep is used, lookup or stored), 2)
that saslprep is used in a way that make it harder to replace it with
something else in the future -- one way that usually makes things hard
is to do the SASLprep as close to the user input as possible, and one
way that usually makes things easier is to do the SASLprep after it has
been sent on the wire.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Mon, 14 Nov 2011 06:15:10 -0500

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

    Simon> Sam Hartman <[email-masked]> writes:
    >> First, I proposed using saslprep on the grounds that we have it
    >> today and that while it's by no means perfect, we'll be in the
    >> same boat as SCRAM, SASL plain and a number of other specs with
    >> regard to moving to a new method for international comparison.
    >> 
    >> The ADs would like us to use something better.  They may be able
    >> to come up with a proposal; if they cannot by tomorrow then we
    >> can move forward with saslprep if we choose.
    >> 
    >> I want to confirm that we'd prefer to publish this draft now than
    >> to wait for another solution to come along if it means waiting
    >> for more than a few days.

    Simon> I support publishing sooner rather than later.

    Simon> "Using saslprep" is a bit under-specified though.  Is there a
    Simon> concrete patch to the document to consider?  I'm concerned
    Simon> that 1) the text may not be complete enough to permit interop
    Simon> (for example, it is common to forget to mention which mode of
    Simon> saslprep is used, lookup or stored), 2) that saslprep is used
    Simon> in a way that make it harder to replace it with something
    Simon> else in the future -- one way that usually makes things hard
    Simon> is to do the SASLprep as close to the user input as possible,
    Simon> and one way that usually makes things easier is to do the
    Simon> SASLprep after it has been sent on the wire.

Use saslprep is in the latest version, although I'm not sure if we
correctly managed to say permit unassigned codepoints (I think that is
lookup mode right?)  We do it as far from the user as possible, although
in one case that's not far at all.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 14 Nov 2011 12:29:05 +0100

Sam Hartman <[email-masked]> writes:

> Use saslprep is in the latest version,

Oops.

> although I'm not sure if we correctly managed to say permit unassigned
> codepoints (I think that is lookup mode right?)  We do it as far from
> the user as possible, although in one case that's not far at all.

I can only find usage of SASLprep in -20:

      *  If the OTP format is decimal, hexadecimal or alphanumeric, then
         OTP is the value of the OTP generated as described in
         Section 3.3 with SASLprep [RFC4013] applied, otherwise it is
         the unnormalized OTP value.

1) Is there a formal definition of what decimal, hexadecimal or
alphanumeric means?  Given a Unicode environment, this is non-trivial.
I'm not certain the requirement even makes sense.  If the OTP is, say,
'º' shouldn't it be subject to SASLprep?

2) I agree SASLprep should be used in lookup mode.

/Simon

---

From: <[email-masked]>
Date: Tue, 15 Nov 2011 03:51:55 -0500

> 'º' shouldn't it be subject to SASLprep?

The intent here is that SASLprep should be used if the OTP is anything other than binary or base64 encoded retrieved from a connected device.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Tue, 15 Nov 2011 04:25:25 -0500

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

    >> OTP is the value of the OTP generated as described in Section 3.3
    >> with SASLprep [RFC4013] applied, otherwise it is the unnormalized
    >> OTP value.
    >> 
    >> alphanumeric means?  Given a Unicode environment, this is
    >> non-trivial.  I'm not certain the requirement even makes sense.
    >> If the OTP is, say, 'º' shouldn't it be subject to SASLprep?
    >> 

    > _______________________________________________ ietf-krb-wg
    > mailing list [email-masked]

Simon, remember that there is an explicit otp-format field; it is well
defined what it means to have a format of one of these.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 Nov 2011 14:57:54 +0100

Sam Hartman <[email-masked]> writes:

> The intent here is that SASLprep should be used if the OTP is anything
> other than binary or base64 encoded retrieved from a connected device.

Agreed, but how is the otp-format values chosen, and what does each
otp-format mean?  Consider an OTP of 'º'.  If that is marked as
'alphanumeric' the OTP will be SASLprep'ed into 'o'.  If it is marked as
'binary' it would be used verbatim.  Without any guidance this seems
like an interop issue to me -- but I recall we realized that we need
external vendor specific documents to complement this specification in
order to get anything interoperable anyway, so the usage of this field
could be another vendor specific detail.

/Simon

---

From: <[email-masked]>
Date: Thu, 17 Nov 2011 09:58:14 -0500

> could be another vendor specific detail.

If the token is a disconnected device then the format will never be 'binary', this format would be used by connected tokens that can return a full-strength binary response.
Therefore, if the OTP value entered by the user happened to contain a 'º' (e.g. it was the user's PIN) then it would be treated as alphanumeric and SASLprep would be applied.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Nov 2011 22:30:37 -0500

The sense of the room in IETF 82 was that   the document is sufficiently
clear about when various otp formats should be used and no change is
required here.

I think that if you publish a new version including the proposed
security considerations text and indicating that saslprep should be used
in lookup mode (unassigned code points permitted) in both case, we can
probably get it approved.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Mon, 21 Nov 2011 11:11:54 -0500

> probably get it approved.

I think the following changes should cover this:

Updated paragraph 3 in section 3.4:

   If the otp-pin field is present in the PA-OTP-REQUEST then the PIN
   value has be value provided by the client.  The KDC SHOULD SASLPrep
   [RFC4013] the value in lookup mode before comparison.

Updated description of the OTP field in section 3.6:

      *  If the OTP format is decimal, hexadecimal or alphanumeric, then
         OTP is the value of the OTP generated as described in
         Section 3.3 with SASLprep [RFC4013] applied in lookup mode,
         otherwise it is the unnormalized OTP value.

New paragraph in section 6.5:

   If PINs contain international characters, similar looking or similar
   functioning characters may be mapped together.  For example, the
   combined and decomposed forms of accented characters will typically
   be treated the same.  Users who attempt to exploit artifacts of
   international characters to improve the strength of their PINs may
   experience false positives in the sense that PINs they intended to be
   distinct are not actually distinct.  This decision was made in order
   to improve usability across the widest variety of input methods.
   Users can choose other methods to add strength to PINs.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Nov 2011 11:42:11 -0500

These changes look good to me.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg