email and phone number canonicalization

[Marius Scurtescu]

Do we have to mandate canonicalization of email and phone number values when used to identify subjects?

[Marius Scurtescu]

From [e-mail]:

There are a series of known attacks using internationalized characters on things like usernames and passwords — which if I understand the threat correctly extends to identifiers like emails.

If we do end up specifying subjects in the SET draft then some text around “PRECIS” handling will be required by the IESG. I say this because previously while I considered it, I had determined it was an issue for the profiles. Though maybe it should be a consideration regardless.

This is an example security consideration you can use as a starting point that was required by the IESG in some past specs. You can rephrase this for the similar threat in subject identifiers. Note: it may require some updating as when SCIM went out so too was the PRECIS standards.

To increase the likelihood that the input and comparison of usernames
and passwords will work in ways that make sense for typical users
throughout the world, there are rules for preparing, enforcing, and
comparing internationalized strings that represent usernames and
passwords.  Before comparing or evaluating the uniqueness of a
"userName" or "password" attribute, service providers MUST use the
preparation, enforcement, and comparison of internationalized strings
(PRECIS) preparation and comparison rules described in Sections 3 and
4, respectively, of [RFC7613], which is based on the PRECIS framework
specification [RFC7564].  See Section 3.4 of [RFC7613] for discussion
on "Case Mapping vs. Case Preparation" regarding "userName"
attributes.

Phil

[Marius Scurtescu]

From [e-mail]:

Do any of the participants support SMTP Extensions for Internationalized Email (RFC6531)? If so, there is substantial work at the IETF on how to properly prepare and compare internationalized strings (See the PRECIS WG).

I am assuming this is an issue, so probably to consider PRECIS work to ensure proper comparison to avoid false matches (this is also important for things like usernames) as part of canonicalization.

See:

• Wikipedia entry on internationalized email - https://en.wikipedia.org/wiki/Email_address#Internationalization
• SMTP Extensions for Internationalized email - https://tools.ietf.org/html/rfc6531
• PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings - https://tools.ietf.org/html/rfc8264
• Mapping Characters for Classes of PRECIS Strings - https://tools.ietf.org/html/rfc7790

Phil

[Marius Scurtescu]

http://lists.openid.net/pipermail/openid-specs-risc/Week-of-Mon-20171009/000389.html

[Marius Scurtescu]

The conclusion from that last face-to-face meeting:

RISC and secevent specs should not require canonicalization since that can cause severe interop issues. The specs can recommend that transmitters and receivers use canonicalization in their respective implementations in general.

In particular, for explicit flows, transmitters should use the exact same format for emails and phone numbers as they are currently using in Id Tokens. Hopefully in Id Tokens they are already canonicalizing, but if not then SETs should use the exact same strings, regardless. If an email is canonicalized in a SET because a secevent spec requires that, and this email after canonicalization ends up different that the one in an Id Token, then the receiver might not be able to look up the account.

And in particular for implicit flows. Transmitters when issuing SETs should use the exact same strings as passed in the add subject APIs. This means that transmitters should store the exact value sent with add subject.

Forcing canonicalization can lead to very subtle issues which are hard to troubleshoot. 99.9% of accounts can be looked up by a receiver, but a very small fraction fails due to incompatibilities in canonicalization.

The above considerations should be added to specs, but not clear to me exactly to which ones.