On Jul 22, 2013, at 8:20 AM, Stefan Winter <stefan.winter@xxxxxxxxxx> wrote: > 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. > [Joe] In the case of multiple authentications multiple identities are exported so I would think that if there are multiple subject names in the certificate then they should all be exported. Something like replacing or with and "When X.509 certificates are used for peer authentication, the Peer-Id is determined by the subject and subjectAltName fields in the peer certificate. " similar for server-ID > 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. > [Joe] I think the main issue is making the realm portion of the NAI consistent with DNS name representation. If we need to we can add something that says: Ongoing work clarifying the usage of UTF-8 in the NAI in [draft-radext-nai] will update or replace [RFC4282]. > Things that might be tackled in TEAP, but my personal preference would > be to do that in EAP core: > [Joe] I do not think we should tackle these issues in TEAP. > * 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 >