Re: Last Call: <draft-ietf-emu-eap-tunnel-method-07.txt> (Tunnel EAP Method (TEAP) Version 1) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I didn't follow TEAP's creation process in enough detail, so may have
missed some information. Apologies if what I write below is noise.

I have two questions about TEAP Version 1 which I don't find
satisfactorily answered in the draft. I wonder if they are worth a
discussion.

Q1: How to determine Server-ID /deterministically/ ?
====================================================
One crucial check for an EAP peer to execute is whether it is talking to
the server it expects to; the primary means are:
a) is the server certificate issued by a CA the EAP peer trusts for the
purposes of EAP?
b) is the name of the server the expected one?

a) is pretty clear, RFC5280 section 6 provides for an algorithm to
determine whether a given certificate was issued by a trusted anchor;
and that RFC is referenced in the TEAP draft.

b) is less clear. The TEAP draft in section 3.4 states
  "the Server-Id is determined in a similar fashion as stated
   above for the Peer-Id; e.g., the subject or subjectAltName field in
   the server certificate defines the Server-Id."

First of all, I think the "e.g." should be an "i.e." because these two
fields are the only part of the certificate that yields server identity
information.

More important than that though is the deliberately indeterministic "or"
in that sentence.

Certificates may carry only a Subject DN, or only subjectAltNames, or
both; if they carry both names, the CN part of the DN may be the same as
one of the subjectAltName values, or it may not.

With the sentence being an "or", EAP peer implementations which are
configured to trust a sever name "aaa.foo.bar" can be presented the same
certificate, but come to different conclusions whether this is the
server they expect, depending on
1) the order in which they inspect the fields (first DN, or first sANs)
2) how they behave if their preferred field does not match or is not
part of the certificate (bail out, or try the other field)
3) how they behave if they observe discrepancies between the two (e.g.
CN matches, but there are sANs and none of them matches the CN).

The draft could make this behaviour deterministic with a few simple rules.

1) prefer the set of subjectAltName:DNS fields over CN
2) fallback to CN if none of the subjectAltName fields matches
3) discrepancies between the two fields are not enforced

Of course, some EAP peer might be configured for "strange" other sANs;
maybe sAN:iPAddr. The validation rules above would then be analogous for
these fields.

Q2: Does the draft need text regarding i18n in EAP-Response/Identity?
=====================================================================
In the recent discussion about ABFAB's eapapplicability document, we
concluded that either EAP or all the EAP methods need patching up to
prevent an encoding/normalisation mess. With TEAP being in IETF LC, I
took a look at how it handles User-Name encoding, normalisation, and
whether there is a nice place inside the TEAP spec to nail things.

TEAP takes the (sensible) approach of not caring how its own context
came to be. It states in its Protocol Overview:

  "TEAP authentication occurs in two phases after the initial EAP
   Identity request/response exchange."

I.e. it simply assumes that EAP peer and EAP server "somehow" found each
other and decided to use TEAP.

It defines Peer ID's in its phase two; for basic auth it sanely mandates
UTF-8 encoding for these (but no word about normalisation); section 4.2.15.

Where TEAPs inner method is EAP - there are no provisions regarding
encoding or normalisation. That is the same situation that EAP (outside)
has as well; TEAP basically becomes an EAP lower layer itself. I guess
the draft expects that the inner method has some notion of a username,
and the inner method will export it to the EAP-Response/Identity of
TEAP's phase 2 EAP exchange.

So in phase 2 of TEAP, there's either UTF-8, or an unknown encoding
inherited from an inner EAP method.
[As an aside: If the inner method if EAP-TLS, then the ambiguity from
question 1 occurs again: the Peer-Id is the subject "or" a
subjectAltName (if there's a set of subjectAltNames in the certificate
*which* is considered the Peer-Id? That should be clarified in the draft).]

TEAP mentions that username privacy is optional. If username privacy is
not used, then the common way of constructing EAP-Identity is by taking
the string that is going to used during phase 2 and put that into the
EAP-Response/Identity. In that case, the encoding being used for that
EAP-Response/Identity is unknown with TEAP; because it may depend on an
inner EAP method which is not known to TEAP, and where TEAP cannot
mandate UTF-8.

If username privacy is used, there is no relation to the phase 2
identity and what's put into EAP-Response/Identity. In particular, the
encoding is not fixed.

TEAP mentions in its section on that topic that NAIs exist, and
references RFC4282, which has known deficiencies in terms of i18n. I
believe it would be better not to mention RFC4282.

It is good that NAIs are not mentioned normatively in that section;
after all Peer-Ids and also anonymous outer identities may or may not be
NAI realms - they can also be simple strings with no particular
structure. But since they can be just that - simple strings with no
structure - there is also no encoding known for these incoming strings.

I know, TEAP doesn't (and doesn't *have to*) care about the outer
identities, because they happen outside of itself and are not of
importance for neither its phase 1 or 2.

And still, some spec needs to say something about the encoding! Or we'll
never have clarity about what's coming in.

After taking a step back, looking at where to properly fix things, I'm
becoming more and more convinced that chasing individual EAP methods to
include normative language about something that happens outside their
own method-protocol; and in TEAP's case being at the whim that some
other EAP method which happens to have been configured as TEAPs inner
method has already done its homework to include provisions about
exporting its inner IDs in a sane format for the TEAP exchange as a
whole to become deterministically encoded is - impractical.

The much more straightforward approach is to mandate EAP (core) to
always force use of UTF-8 for EAP-Response/Identity.

In summary (kudos for reading this far!)
==========
IMHO, TEAP should fix the following points

* Peer-Id and Server-Id should become deterministic.
* When discussing NAIs, mentions of RFC4282 should be removed, or
qualified so that readers of spec are urged to read (exclusively) its
successor as soon as it becomes available.

Things that might be tackled in TEAP, but my personal preference would
be to do that in EAP core:

* Specify the encoding in which phase 2's Peer-Id is used during the EAP
negotiation that precedes the TEAP exchange. If Peer-Ids are not used
(i.e. identity privacy support is enabled), specify in which encoding
the privacy-preserving identity hints are expected.

Thanks for reading this :-)

Note how I did not go into detail about normalization; similar
principles apply here, but the mail is long enough.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]