Subject: [eap] Re: passphrases in EAP

From: [email-masked] ([email-masked])
Date: Fri, 2 May 2003 17:55:53 +0300

Hi,

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.=20
=20
    In the absence of other guidance, the Identity MAY be a=20
    Network Access Identifier (NAI) conforming to [RFC2486],=20
    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=20
      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 =20
    the user, it SHOULD be converted into bytes using UTF-8=20
    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]."

Best regards,
Pasi

> -----Original Message-----
> From: ext Lauri Tarkkala [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2003 2:36 PM
> To: [email-masked]
> Subject: [eap] passphrases in EAP
>=20
>=20
>=20
> 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.
>=20
> Lauri
>=20
>=20
> Interoperability problems in passphrase authentication protocols.
>=20
> 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:
>=20
> 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.=20
>=20
> 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:
>=20
> - Alphabet the password is defined in.
>=20
> - Derivation of shared secret from password.
>=20
> 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.=20
>=20
> This leads to obvious problems. If the user=20
> 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=20
> (e.g. out-of-band) vendor identification for the peer.
>=20
> These pitfalls should be avoided in the future.
> I propose that the working group standardize the=20
> following  functions:
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> This would require introduction of two EAP-MD5 methods.
>=20
> --=20
> Lauri Tarkkala
> SSH Communications Security Corp

---

From: [email-masked] (Lauri Tarkkala)
Date: Fri, 2 May 2003 17:43:59 +0300

> something for methods specified in 2284bis.

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?

Lauri

-- 
Lauri Tarkkala

---

From: [email-masked] (Henrik Levkowetz)
Date: Fri, 2 May 2003 23:03:32 +0200

Lauri,

	There's something I don't quite understand here.

        The proposed encoding is UTF-8, which is unicode(16) characters
encoded as an octet sequence. Now, while it is true that there exists
enough variations on chinese ideographs used in classical literature
that not all can be represented in unicode(16), I'm not aware of any
existing set of computer character codes which cannot be represented in
unicode. Maybe I'm mistaken here?

        But if I'm not mistaken, wherein lies the problem in specifying
UTF-8 encoding? It seems to me that UTF-8 would provide a normalization
which would work with all current input locales, with no possibilities
of mismatch between server representation and client representation of
passphrase?

	Henrik

> to an EAP method (with the possible exception of some legacy

	Henrik

-- 
Error message in Haiku form:

  Having been erased,
  The document you're seeking
  Must now be retyped.

    -- Judy Birmingham

---

From: [email-masked] (Joseph Salowey)
Date: Fri, 2 May 2003 14:58:04 -0700

I think the stringprep RFc may provide some guidence in this area.

http://www.ietf.org/rfc/rfc3454.txt

SASL is working string preparation procedure for usernames and
passwords.  Kerberos is looking at defining something similar (or
perhaps will use the same spec).  

http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-00.txt

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Henrik Levkowetz
> Sent: Friday, May 02, 2003 2:04 PM
> To: Lauri Tarkkala
> Cc: [email-masked]; [email-masked]
> Subject: Re: [eap] Re: passphrases in EAP
> 
> 
> Lauri,
> 
>         The proposed encoding is UTF-8, which is unicode(16) 
> characters encoded as an octet sequence. Now, while it is 
> true that there exists enough variations on chinese 
> ideographs used in classical literature that not all can be 
> represented in unicode(16), I'm not aware of any existing set 
> of computer character codes which cannot be represented in 
>         But if I'm not mistaken, wherein lies the problem in 
> specifying UTF-8 encoding? It seems to me that UTF-8 would 
> provide a normalization which would work with all current 
> input locales, with no possibilities of mismatch between 
> server representation and client representation of passphrase?
> 
> 	Henrik
> 
> > > 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.
> > 
> 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 holds passphrase expressible in alphabet X, but 
> not alphabet 
> > Y.
> > 
> > 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).
> 
> 
> 	Henrik
> 
> -- 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>

---

From: [email-masked] (Lauri Tarkkala)
Date: Mon, 5 May 2003 11:46:33 +0300

> unicode. Maybe I'm mistaken here?

No you are not. I agree fully, that if all implementations were to
use UTF-8, there would be no problem, but OTOH I do not find it 
desirable to break interoperability between existing EAP MD5-Challenge
implementations (which do not seem to use UTF-8). This is why
I proposed a tagging mechansim (one, which could be improved
in many ways, I admit) to overcome the backward compatibility problem.

Lauri

---

From: [email-masked] (Lauri Tarkkala)
Date: Mon, 5 May 2003 12:12:45 +0300

> http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-00.txt

Thank you for these references. They shed some light on previous
work in this area, and they seem quite applicable here.

The backwards compatibility problem still persists. Noting
that the EAP WG is chartered to "improve the interoperability of
the existing EAP protocol", and with the experience of 
having developed EAP/PPP/RADIUS implementations in the past I
would not like to break backwards compatibility with existing
implementations. The whole jungle that is PPP/RADIUS and associated
technologies tends to evolve somewhat unpredictably. Even if that
interoperability is currently a result of de-facto conventions and
not standardization.

Might then the following approach be more to the WG's liking ?

1. Leave current EAP-MD5/OTP/GenericTokenCard as is (e.g. they use
   no map, implementor must guess that US-ASCII is correct choice).

2. Specify that in all methods UTF-8 SHOULD be the preferred
   representation of readable strings.

3. Reference a stringprep profile for usernames and passwords for
   preparsing unicode strings, which MUST be used, if unicode is used.

4. Implementors/method developers SHOULD NOT use other representations
   for readable strings. 

5. Define new type code for EAP-MD5/OTP/GenericTokencard that use
   Unicode for representing passphrases ?

This is ofcourse conditional on the existence of such a stringprep
profile. Indeed, it would probably be desirable to have one such draft
for the whole security area of IETF, although that is pretty much out
of scope for EAP.

These guidelines however, should guarantee interoperability (of both
implementations and passphrases) in most passphrase-based methods.

Lauri

---

From: [email-masked] (Jari Arkko)
Date: Mon, 05 May 2003 14:49:33 +0300

> in many ways, I admit) to overcome the backward compatibility problem.

Isn't UTF-8 encoding for plain ASCII characters the same as in ASCII? (I
didn't bother to actually go and read the UTF-8 spec so I might
be wrong here but that's what I have assumed.)

If so, making RFC2284bis use UTF-8 would *not* break interoperability
as far as plain ASCII characters are concerned. However, extensions
such as scandinavian characters are encoded with different bit
patterns, and if a password contained them interoperability would
be broken. Then again, I'm not quite sure what interoperability
we have right now for those things since 2284 did say ASCII.

--Jari

---

From: [email-masked] (Tom Porcher)
Date: Mon, 05 May 2003 08:32:27 -0400

UTF-8 is an encoding of up to 32-bit wide characters, so the "Unicode" 
(16-bit) restriction does not apply.  The characters below 128 (i.e. 
ASCII) are represented exactly as ASCII in UTF-8, so strings of ASCII 
characters are also strings of UTF-8 characters.

UTF-8 is defined in International Standard ISO/IEC 
10646-1:1993/Amd.2:1996: Information Technology - Universal 
Multiple-Octet Coded Character Set (UCS): Architecture and Basic 
Multilingual Plane. Amendment 2: UCS Transformation Format 8 (UTF-8) (phew!)

FWIW, both the EAP SIM and EAP AKA drafts require usernames to conform 
to RFC 2486 "The Network Access Identifier".  This RFC limits the 
username character set to 82 characters unless quoted in hexidecimal.
                 --Tom Porcher

-- 
Tom Porcher          | [email-masked]    voice: 978.371.3980 x108
Consulting Engineer  | http://www.funk.com   fax: 978.371.3990
Funk Software, Inc.  | Concord, Massachusetts, USA, Earth

---

From: [email-masked] (Jari Arkko)
Date: Mon, 05 May 2003 17:15:10 +0300

> characters are also strings of UTF-8 characters.

If so, maybe we should mandate UTF-8? (But see bottom of the e-mail
for a special case about Identity Response.)

Whose implementation would break if we were to do that?

> username character set to 82 characters unless quoted in hexidecimal.

Hmm... good point. I can see that we don't actually say *anything*
about the format in the Identity Response packet in 2284bis. If we
can mandate anything there, my guess is that NAI would be a more logical
choice here than UTF-8. The question is if we can mandate this -- any
reasons not to?

--Jari