Subject: [eap] passphrases in EAP

From: [email-masked] (Lauri Tarkkala)
Date: Wed, 30 Apr 2003 14:36:17 +0300

I have unfortunately not had time to follow the WG work
actively all the time, so my apologies if this item
has already been discussed.

Lauri

Interoperability problems in passphrase authentication protocols.

Submitter name: Lauri Tarkkala
Submitter email address: [email-masked]
Date first submitted: April 30, 2003
Document: draft-ietf-eap-rfc2284bis-02.txt
Comment type: general
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.

-- 
Lauri Tarkkala
SSH Communications Security Corp