Tunnel Extensible Authentication Protocol (TEAP) Version 1
draft-ietf-emu-eap-tunnel-method-10

Version -09 makes the negotiation process in Section 3.1 much clearer to me; thanks very much for addressing that.

I note that the shepherd writeup included key information about reviews from outside the working group.  Thanks for that; it's very useful.

I can't in good conscience make this a DISCUSS point because really, the best you're going to be able to do is hand-wave or wait on a not-yet-published document. But 4.2.15 (like a bunch of other documents) is really introducing an "...a miracle occurs..." solution. It is presuming that there is a user-input username and password in UTF-8, but no discussion of normalization or mappings. If you are OK with false negatives (i.e., in some circumstances people are going to type things that they are absolutely sure are their usernames and passwords, but they are going to fail, and they will be unable to type their "true" usernames or passwords), then you're probably OK doing nothing. If that would be a really bad outcome, to make it more resilient you could look at:

   http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/

(This document is not just about SASL, the filename notwithstanding.) I'd like to say that the document will be published quickly, and maybe if you all pushed on the PRECIS folks it might, but I can't make any promises. And I wouldn't suggest using RFC 4013, because it's going to be obsoleted by the above (for good reasons).

I'm glad to discuss this with the authors or the WG, but I won't force you to DISCUSS it.

I considered balloting Discuss, but I'm assuming that either I'm missing something really obvious, or this will be an easy fix ...

In 3.1.  Version Negotiation

      If the TEAP server does not support the version number proposed by
      the TEAP peer, it MAY terminate the conversation with EAP-Failure
      or negotiate for another EAP type.  Otherwise the TEAP
      conversation continues.

I'm wondering if "MAY terminate the conversation" is what you mean when the TEAP peer doesn't propose a version number that the TEAP server supports.

I'm reading "otherwise the TEAP conversation continues" as saying that the two alternatives given are the only choices when the TEAP server doesn't support a proposed version number. Did I get that right? 

If you're expecting the TEAP server to do one of those two things, something like "MUST terminate the conversation unless the TEAP server negotiates for a different version number" might be clearer.

If there are more than two alternatives, it would be helpful to rephrase this text so it's clear that the TEAP server isn't limited to those two alternatives.

(I should have mentioned that I agree with Martin's Discuss, but one Discuss on those topics is enough)

Thanks for handling my discuss.

--- didn't check comments against -10 

This was discuss point (1), not a comment:

(1) 3.4: when x.500 names or SubjectAltNames are
"exported" is it clear how those are formatted? Maybe a
pointer to where that's defined would be good in case
implementers get it wrong. You might also want to warn
here (or somewhere) about names that contain a null byte
in case that attack is used e.g. with a TLS server cert
subject name like "CN=www.paypal.com\0.badguy.com" Even
though that's really a PKI failure, not detecting it here
would be bad too.

older comments...

- 3.2: You're allowing TLS compression. Is there the
potential for something like a CRIME attack here? I guess
not, given that there's no way to programatically get a
peer or inner method server to send attacker-chosen data.
Is that correct? (Just checking.)

- 3.2.2: Since a PAC-lifetime is a wall-clock time then
it would provide a way to correlate old and new sessions
(i.e. act as a fingerprint) if its ever carried in clear.
Can that happen?

- 3.3.3, 1st para: what does "clear text" mean here? Do
you mean within the TLS tunnel or not? I hope you do mean
within the TLS tunnel, but I think you need to be
clear(er) in any case.

- 3.8: this says mutual auth "results" if the peer trusts
the server cert belongs to the server - that sounds
wrong, isn't it?

- 3.8.1: I think you need an s/MAY/MUST/ here - you say
the request "MAY be issued only ..." but I think you mean
"MUST be issued only..."

- 3.8.2: Just checking, and I may be wrong here. Say if I
establish a TLS server-auth tunnel and then renegotiate
to get TLS client-auth (with id privacy) as well, and
then the Peer wants to get a new cert.  This calls for
the tls-unique for the initial server-auth TLS session to
be used in the pkcs#10.  Am I reading it right? Is that
ok? I think it is, but just want to check since its
pretty confusing;-)

- The secdir review [1] raised a couple of questions that
I think would be good to answer. Did I miss that answer?

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04106.html