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

From: [email-masked] ([email-masked])
Date: Wed, 7 May 2003 17:26:25 +0300

Lauri Tarkkala wrote:

> We must make the following decision:
>=20
> 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.
>=20
> 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).

A standards-track RFC can't contain a normative reference to an
I-D, but informative references are OK. I think we could write
this so that the reference to SASLPREP would be considered
informative (see below).=20

I don't think D1 is an option.

> No WG member has made explicit statements regarding the following:
>=20
> A. Is it OK, that passphraseses MAY NOT be inter-operable between
>    passphrase-keyed EAP methods?

Depends. Certainly we should try to minimize any
interoperability problems, but 2284bis may not be the
appropriate place to do it.

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

Yes, for some levels of "exactness" :-)

We can't exactly define the behavior without a stringprep
profile, and we certainly don't want to wait for SASLPREP to
become RFC.=20

I think we could say something like "Behavior for non-ASCII=20
characters is undefined, and will be clarified in a future=20
revision of this document. Our guess is that it will resemble=20
SASLPREP followed by UTF-8.".

Something like that would provide enough information to build=20
interoperable implementations, yet make the reference=20
informative. (Though I'm not sure if IESG will allow leaving
the behavior undefined in standards-track RFC?)

> 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:
>=20
> Add to section "2" after point [4].
>=20
> "[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."

I don't think we should add such a requirement here. Certainly
an EAP method should be able to define that it uses a shared
secret that MUST contain only ASCII characters (or only
characters A-Z except Q, or whatever).

Also, no implementation will ever support entering ALL
characters defined in Unicode.  Implementations will support
entering some subset of Unicode characters, and I don't think=20
2284bis is an appropriate place to specify what that
subset should be.

Best regards,
Pasi
=20

---

From: [email-masked] (Lauri Tarkkala)
Date: Wed, 7 May 2003 17:14:05 +0300

> appropriate place to do it.

I feel that if it is not done in RFC 2284bis, then I
fear that it will not be done at all.

> characters A-Z except Q, or whatever).

I feel that our opinions could be unified slightly, by 
classifying passphrase methods further than in my first post:

1. EAP methods keyed by an arbitrary bitstring.
  
   1a) Shared secret is ALWAYS generated by a RNG.
   1b) Shared secret is derived from a passphrase.

2. EAP methods keyed by strings over some other alphabet.

Now my interest is defining the behaviour in case 1b, the intent
being to have standardized "how to derive the shared secret
from a passphrase" in the case the "shared secret is an arbitrary
bitstring" (this may have gotten lost in the discussion, but this
was the point in my frist post on the topic also, although there
I did not explicitly mention the second category). EAP methods with
limited alphabets certainly will have limited needs to be
interchangeable with other EAP methods, so these are IMHO not really
the current concern.

As such I still feel my proposal is relevant, although the wording
(and place in the specification) may require improvement. Note
that I phrased my proposal as an implementation option. The
implementation was left free to provide the shared secret in ANY form
to the EAP method, as long as it supported one standard way of doing
it.

Lauri

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