Subject: [eap] Re: Issue 120: Passphrases in EAP

From: [email-masked] ([email-masked])
Date: Wed, 7 May 2003 14:23:07 +0300

Bernard Aboba wrote:

> Given all of this, it strikes me that encoding passphrases as=20
> UTF-8 is in keeping with the general direction of RFC 2284bis,=20
> and so Pasi's suggestions (see below) seem reasonable to me.
>=20
> If there are EAP implementations that would be broken by the proposed
> fixes, now would be a good time to step forward.

I had a discussion with Patrik F=E4ltstr=F6m about UTF-8 in NAIs,
and he pointed out that just specifying an encoding method
(UTF-8) is not enough. For instance, the character in Patrik's=20
name can be represented in Unicode as "U+E4" (latin small=20
letter a with diaeresis) or "U+41 U+308" (latin small letter a +=20
combining diaeresis). Both are equally valid, but obviously=20
implementations have to use the same form for a password or=20
they won't interoperate.

Fortunately (phwww....), we don't have to know more about this,
and can simply cite an appropriate RFC. Here's an updated text:

Add to 5.4 (MD5-Challenge), before Type:

"Note: [RFC1994] treats the shared secret as an octet string,
and does not specify how it is entered into the system (or if it
is handled by the user at all). For EAP MD5-Challenge method, if
the shared secret is a passphrase entered by the user,
implementations MAY support entering passphrases with non-ASCII
characters. In this case, the input SHOULD be processed using an
appropriate stringprep [RFC3454] profile, and encoded into
octets using UTF-8 encoding [RFC2279]. At this writing, no
suitable registered stringprep profile exists, but one is being
worked on [SASLPREP]."

Add to 5.5 (OTP), before Security Claims:

"Note: [RFC2289] does not specify how the secret pass-phrase is
entered by the user, or how the pass-phrase is converted into
octets. For EAP OTP method, implementations MAY support entering
passphrases with non-ASCII characters. See Section 5.4 for
instructions how the input should be processed and encoded=20
into octets."

Add to 5.6 (GTC), before Security Claims:

"Implementations MAY support entering a response with non-ASCII
characters. See Section 5.4 for instructions how the input should=20
be processed and encoded into octets."

Add to informative (?) references:

[RFC3454]=20
Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ('stringprep')", RFC 3454, December 2002.

[SASLPREP]=20
Zeilenga, K.D., "SASLprep: Stringprep profile for user names and=20
passwords", draft-ietf-sasl-saslprep-01 (work in progress), May 2003.

Best regards,
Pasi

---

From: [email-masked] (Lauri Tarkkala)
Date: Wed, 7 May 2003 15:00:30 +0300

Sorry about all the posts on this issue, but I promise this will
be (one of) the last (ones). Please bear with me... ;-)

On Wed, May 07, 2003 at 02:23:07PM +0300, [email-masked] wrote:
> [SASLPREP] 
> Zeilenga, K.D., "SASLprep: Stringprep profile for user names and 

We must make the following decision:

D1) Specify our own stringprep profile.
D2) Wait till the SASLprep one makes RFC status, and then cite it.
D3) Leave the issue to be resolved later.

Pasi's wording above seems to imply decision "D2" (an RFC will
probably not get accepted by the IESG if it references an I-D,
as all probably know).

And on a more general note:

The WG seems to be uninterested in introducing separate EAP-MD5
method, which would be strictly unicode compliant (e.g. there
would be no ambiguity about what character set is used to encode
the passphrase and how to do it). This means, that in the short term,
even with a published and matured EAP specification, the following 
order of preference would be the most sensible to use in
negotiating an authentication method in a widely-used PPP
implementation:

1. MS-CHAPv2
2. MS-CHAPv1
3. EAP
   -> Then try methods which define passphrase encoding strictly
   -> Then methods which do not.

This will not change, untill a better order of preference exists
for achieving interoperability, even if the first two methods
are only published as Informational RFC's. Some of you may have the
luxury of being able to operate in a pure US-ASCII environment,
or in an environment with a single 8-bit character set (e.g. Latin1),
others are not so lucky and neither do they have the technical
understanding to configure these features.

Note that MS-CHAP has been the ONLY workable solution as a passphrase
protocol that can be used all over the globe, and which can 
handle pretty much any passphrases present in the password database.
I hate to trumpet a proprietary protocol, but this is the way it is.

No WG member has made explicit statements regarding the following:

A. Is it OK, that passphraseses MAY NOT be inter-operable between
   passphrase-keyed EAP methods?

B. Is it OK, that the only mandatory EAP method, does not exactly specify
   how it should be used in Unicode environments?

If the WG feels that the answer to question "A" is NO (as I do),
then I would recommend adding the following note to the draft:

Add to section "2" after point [4].

"[5] If the EAP method is keyed by a human-readable passphrase,
     then it MUST be possible to provide that passphrase in Unicode,
     which is transformed using stringprep [RFC3454] profile XXX
     [RFCXXX] before it is input into the EAP authentication method.
     This SHOULD be the default mode of operation."

This leaves the implementations to use a different mode of operation
if they choose, but should hopefully steer all implementations of
methods toward interoperabiity, without impacting individual method
specifications. Furthermore, after the discussion on this list,
I feel that it is better to tackle this as an "implementation issue"
in the specification, than as a "method specification issue".

I personally feel that the answer to question "B" should be NO,
and suggest a slight rewording of Pasi's suggestion (change
of priorities).

"For EAP MD5-Challenge method, if the shared secret is a
 passphrase entered by the user, implementations MUST support
 entering passphrases with non-ASCII characters. In this case, the
 input MUST be processed using the stringprep [RFC3454] profile XXX
 [RFCXXXX] and encoded into octets using UTF-8 encoding [RFC2279].
 This is in accordance with item [5] in section 2."

Lauri

-- 
Lauri Tarkkala
SSH Communications Security Corp
http://www.ssh.com/