Subject: [eap] RE: passphrases in EAP

From: [email-masked] ([email-masked])
Date: Fri, 2 May 2003 19:36:31 +0300

Hi,

Lauri Tarkkala wrote:

> 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).
>=20
> A simple example:
>=20
> - Client wishes to authenticate with EAP using a shared-secret=20
>   scheme to Server, where server assumes alphabet Y for=20
>   on-the-wire representation.
>=20
> - Client holds passphrase expressible in alphabet X, but not=20
>   alphabet Y.
>=20
> - Authentication will not succeed. Interoperability would require
>   that the user know the EAP methods used before he/she chooses
>   his/her password!=20
>
> 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).
>=20
> 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".

Well, most EAP methods seem to treat the shared secret internally
as a string of raw octets, with no assumptions about alphabets=20
at all. A user interface for entering passwords obviously
has to choose some method of converting the user input
into octets.

In the example above, the EAP server doesn't probably even
know what character set or conversion was used by the UI (the
password database contains just the octets), so it can't=20
"negotiate" this with the client.=20

So, I don't quite see what would be achieved by defining
two separate methods, one for "binary" secrets and one
for "text" secrets. It would provide a hint to the UI
how to ask for the password (maybe "binary secrets"
would be entered in hexadecimal format?), but=20
presumably the user already knows which one should=20
be used, since he knows what the password is and=20
already has entered it somewhere (when it was=20
stored in the password database).

Best regards,
Pasi

---

From: [email-masked] (Lauri Tarkkala)
Date: Fri, 2 May 2003 18:55:58 +0300

On Fri, May 02, 2003 at 07:36:31PM +0300, [email-masked] wrote:
> password database contains just the octets), so it can't 
> "negotiate" this with the client. 
> 
> would be entered in hexadecimal format?), but 
> presumably the user already knows which one should 
> be used, since he knows what the password is and 
> already has entered it somewhere (when it was 

I probably communicated this badly, sorry about that.

When the server sends the "passphrase-derived key"-bit
to the client, the client knows that it can ask the
user for the passphrase, and transform it into UTF-8
and use this as the shared secret. It would indicate
that it had done so, by setting the "passphrase-derived
key" bit in it's responses.

The absence of the "passphrase-derived key"-bit, would
indicate, that a bitstring _IS_ the secret 
input into the EAP method by the client (e.g. the current
behaviour for most current EAP methods), instead of
some secret derived from a passphrase (normally as
an encoding using some character set).

The hint, as you call it, would not be to the UI, but to
the implementation of the authentication method in the
client and server. Some representation must ALWAYS be used
for the passphrase, in any authentication method. The hint
would be directed to implementations, and they would use it to
select the encoding used for generating these representations.

Example:

- I try to authenticate to some server, with my neat unicode
  passphrase. The server, being EAP-bis compliant, sends me
  an EAP-MD5 message with the "I support the hint-bit"-bit set.

- My client, noticing this encodes my passphrase using UTF-8,
  and uses this as input to the MD5 hash, and keeps the hint
  bit set.

- If the hint bit were not set. Then my implementation would
  have to arbitrarily choose an encoding, and use this. I could
  only hope that, this was the same encoding used by the server
  side implementation. 
  
  Recall the example about CHAP and MS-CHAPv2, which
  use different representation of the same passphrase, with
  MS-CHAPv2 being able to represent passphrases that most
  CHAP implementations do not support.
 
There is the usability aspect (I would strongly question
some users capability to understand that there are
several character sets in which to represent passpharses ;)
and the interoperability/implementation aspect.

Lauri

-- 
Lauri Tarkkala
SSH Communications Security Corp