Subject: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 14 Aug 2013 10:58:31 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-emu-eap-tunnel-method-07: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

These discuss points are more questions I'd really like
answered than blocking points (depending on the answers I
guess:-) but I expect should be easily resolved.

(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.

(2) 5.2, at the end: this adds a dependency on the
TLS-PRF.  I don't suppose TLS1.3 will be a big enough
change for that to be a problem, but what if it was? E.g.
if someone convinced the TLS WG to use IKE instead? Do
you really need the same PRF or could you pick one for
TEAP and remove the dependency? Same question for the MAC
in 5.3.

(3) 7.3: you have a MAY for this separation but also
define what would become a cleartext password set of TLVs
on the link between the two boxes here. Could you not at
least REQUIRE protection (e.g. using IPsec) of that link
if the basic password method will be used?

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

- 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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Aug 2013 16:11:29 -0400

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

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

we're talking about the server and peer ID?
I asked the same question and we pondered it during an IETF meeting and
all came to the conclusion that the formatting doesn't matter.
We want to specify what's included but we don't need to specify  how
it's formatting.

The argument that convinced me to drop the issue was that peer id and
server id didn''t seem to be used and probably aren't interoperable.
Someone decided somewhere that EAP methods should have these but didn't
define them well enough to be useful.
    Stephen> (3) 7.3: you have a MAY for this separation but also define
    Stephen> what would become a cleartext password set of TLVs on the
    Stephen> link between the two boxes here. Could you not at least
    Stephen> REQUIRE protection (e.g. using IPsec) of that link if the
    Stephen> basic password method will be used?

I would object fairly strongly to IPsec here because I don't think it's
reasonably implementable by the EAP implementation.
Basically no implementation of EAP is going to be in a good position to
manipulate the SPD and figure out whether IPsec is actually used.

I think RADIUS over TLS and Diameter over TLS are much better security
mechanisms for this.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Aug 2013 15:35:55 +0100

Hi Sam,

> define them well enough to be useful.

Ok, I'll make that a comment. Not sure if the text about
names with null bytes is worth including or not but handling
that as a comment is fine.

> I think RADIUS over TLS and Diameter over TLS are much better security

Sure, those would be fine.
But the question remains whether the spec needs to say that some
such mechanism is required to be used or not.

S.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Aug 2013 14:02:40 -0400

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

    Stephen> whether the spec needs to say that some such mechanism is
    Stephen> required to be used or not.

It's very rare we have required-to-use security; typically we settle for
MTI.

I mean it's good operational advice to require the channel be secure.
I'm not sure I'd use encryption within a single box or between VMs on
the same hypervisor...but I support a strong operational recommendation
and a requirement that TEAP server implementations supporting this
separation support confidentiality and integrity for the channel to the
inner EAP.