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

From: [email-masked] (Bernard Aboba)
Date: Tue, 6 May 2003 11:25:19 -0700 (PDT)

With respect to UTF-8, we have added the following to the terminology
section in RFC 2284bis:

   Displayable Message
             This is interpreted to be a human readable string of
             characters, and MUST NOT affect operation of the protocol.
             The message encoding MUST follow the UTF-8 transformation
             format [RFC2279].

Also, Section 5.1 states that the EAP-Request/Identity is encoded as UTF-8
if it contains a displayable message. Section 5.2 says that Notification
Requests are encoded as UTF-8.

Given all of this, it strikes me that encoding passphrases as UTF-8 is in
keeping with the general direction of RFC 2284bis, and so Pasi's
suggestions (see below) seem reasonable to me.

If there are EAP implementations that would be broken by the proposed
fixes, now would be a good time to step forward.

-------------------------------------------------------------------
Issue 120: Passphrases in EAP
Submitter name: Lauri Tarkkala
Submitter email address: [email-masked]
Date first submitted: April 30, 2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-April/001107.html
Document: EAP-02
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

Several of the PPP/EAP authentication protocols
are in essence "password authentication protocols"
(PAP, CHAP, EAP-MD5). This means that the shared
secret is in essence a string in some alphabet
(most often US-ASCII), as opposed to the more
low-level view of a bitstring.

Currently the specifications of these protocols
define the shared secret as an arbitrary string
of octets. This has caused in practice a serious
interoperability problem, leaving implementations
free to define the following:

- Alphabet the password is defined in.

- Derivation of shared secret from password.

As an example some implementations assume CHAP to
encode the password as US-ASCII (or Latin-1 or
some other 8-bit alphabet) and MS-CHAPv2 to
encode the password as UCS-2.

This leads to obvious problems. If the user
actually has characters in his/her password not expressible
in US-ASCII. He/she/it should have sufficient know-how
to be able to disable CHAP when negotiating an authentication
protocol. An implementation also might have to guess
the alphabet to use. These settings might also
differ from system to system. In some cases one could
try to deduce an intelligent guess based on some
(e.g. out-of-band) vendor identification for the peer.

These pitfalls should be avoided in the future.
I propose that the working group standardize the
following functions:

a) If an authentication protocol is keyed by a "passphrase",
then the algorithm used to derive a representation
of a shared secret. If any cryptography is involved,
the protection of the shared secret (if performed)
should still be left to the individual EAP method.

b) The alphabet to be used for this (assuming the WG feels
that a superset alphabet exists), or if the WG feels
that it is not prudent to specify a superset alphabet
at this point in time, a tagging mechanism in the protocol
to denote the alphabet used in mapping a passphrase to a
bitstring. The current draft specifies that the UTF-8
is used to represent all human-readable data.

An acceptable solution would be to state, that ALL
human readable data in ALL EAP methods (except methods
specified before xx.yy.zzzz) must be represented using
UTF-8. This would include passphrases. Also the
alphabsets used in methods before xx.yy.zzzz should
be defined, by a poll checking current implementations.

This would require introduction of two EAP-MD5 methods.

[Pasi Eronen]:

Hmm, good point; we already specify that displayable messages
use UTF-8, but the same problem also applies to input data.
While I'm not so sure that we should try to force all existing
EAP methods to use UTF-8, we probably should at least recommend
something for methods specified in 2284bis.

Here's suggested text (written as MAY/SHOULD, not MUST).

Add to end of section 5.1:

"EAP does not place any other requirements on the contents
of the Identity Response, as different representations may
be appropriate in different contexts.

In the absence of other guidance, the Identity MAY be a
Network Access Identifier (NAI) conforming to [RFC2486],
with the following exceptions allowed:

- The username portion MAY be empty. This can be useful with
EAP methods that have their own identity protection mechanism,
but use the realm portion to route messages to the correct
backend server.
- The username portion MAY contain Unicode characters greater
than U+007F encoded using UTF-8 [RFC2279]."

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

"Note: [RFC1994] treats the shared secret as a byte 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, it SHOULD be converted into bytes using UTF-8
encoding [RFC2279]."

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, the pass-phrase SHOULD be
encoded using UTF-8 [RFC2279]."

Add to 5.6 (GTC), before Security Claims:

"If the data entered by the user contains non-ASCII
characters, it SHOULD be encoded using UTF-8 [RFC2279]."

[Lauri Tarkkala]:

Your proposed solution is IMHO not satisfactory, for the
simple reason that the alphabet used to represent the passphrase
is a parameter in selecting the acceptable authentication method
(or the used authentication method is a parameter in choosing the
passphrase).

A simple example:

- Client wishes to authenticate with EAP using a shared-secret scheme
to Server, where server assumes alphabet Y for on-the-wire
representation.

- Client holds passphrase expressible in alphabet X, but not alphabet Y.

- Authentication will not succeed. Interoperability would require
that the user know the EAP methods used before he/she chooses
his/her password!

A requirement for an acceptable solution IMHO is that the
character set used for the passphrase SHOULD NOT be related
to an EAP method (with the possible exception of some legacy
methods).

A user should not need to know that
"if my password contains the Japanese Kanji <x> I can
only authenticate using the EAP method xyzzy".

I do agree with you, that forcing all EAP methods into the
same alphabet is not wise. I also think that interoperability
with existing EAP-MD5/etc implementations is important (otherwise
implementors would still have to sniff out, based on some indidcators
about the peer vendor, what encoding to use).

I feel that a better solution would be to classify EAP methods
according to the key-type used into "passphrase-keyed methods"
and "binary-keyed methods". Ideally, each method would have
an instance in both classifications. This could be achieved
by reserving a bit in the type field of a method (with the
obvious consequence of halving the namespace), e.g. assuming
"passphrase-keying" is indicated by bit 6:

- EAP-MD5 keyed by a binary string would be method 0x05.
- EAP-MD5 keyed by a passphrase in UTF-8 would be method 0x45.

The bit would have the following semantics:

- If the passphrase-keying bit is set by the authenticator, then it
means "authenticator supports passphrase-keying".

- If the passphrase-keying bit is set by the authenticatee, then it
means "that key used is a passphrase in UTF-8 encoding".

Any opinions?

Any ideas on some better place to find bits for this indication?

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 7 May 2003 07:37:30 -0700 (PDT)

Lauri Tarkkala wrote:

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

In this particular case, the reference applies to a SHOULD so it
is hard to argue that it is non-normative. This would result in a
Reference Hold in the RFC Editor queue until the normative reference is
resolved. We're trying to avoid this fate for RFC 2284bis if at all
possible.

The possible options are either to remove the SHOULD (such as demoting it
to a should or may), or to make it clear that the SASLprep document is
only one possible solution and that there might be others.