Tunnel Extensible Authentication Protocol (TEAP) Version 1
draft-ietf-emu-eap-tunnel-method-10
Yes
(Sean Turner)
No Objection
(Adrian Farrel)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Richard Barnes)
(Ted Lemon)
Note: This ballot was opened for revision 07 and is now closed.
Sean Turner Former IESG member
Yes
Yes
(for -07)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -07)
Unknown
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2013-10-01 for -09)
Unknown
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.
Jari Arkko Former IESG member
No Objection
No Objection
(for -07)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -07)
Unknown
Martin Stiemerling Former IESG member
(was Discuss)
No Objection
No Objection
(for -07)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2013-08-15 for -07)
Unknown
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.
Richard Barnes Former IESG member
No Objection
No Objection
(for -07)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2013-08-09 for -07)
Unknown
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)
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2014-01-08)
Unknown
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
Ted Lemon Former IESG member
No Objection
No Objection
(for -07)
Unknown