Subject: [Emu] Stephen Farrell's No Objection on draft-ietf-emu-eap-tunnel-method-10: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 08 Jan 2014 17:26:02 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-emu-eap-tunnel-method-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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