Re: [abfab] Comments on draft-linus-abfab-ephemeral-keying-00

[Linus Nordberg <[e-mail]>]

Jim, thanks for the comments and sorry for the delay. Things have
improved for me since last week w.r.t. responsiveness.

"Jim Schaad" <[e-mail]> wrote
Tue, 18 Feb 2014 11:13:09 -0800:

| Section 2. - I am not sure if you are trying to restrict to the conversation
| between the initiator and the acceptor based on the fact that you are
| throwing in RADIUS.  There is no RADIUS spoken here.  

I agree that this is confusing. Restricting to traffic between initiator
and acceptor is not enough in this section even if the suggested
solution is limited to adding additional encryption to that stretch.

Changing section 2. to read

--8<---------------cut here---------------start------------->8---
This section describes the information available to a passive observer
of an {{I-D.ietf-abfab-arch}} authentication, working from the lowest
layers of the protocol stack upwards.
--8<---------------cut here---------------end--------------->8---


| Section 2.1 - para #2 - The first sentence is just wrong.  No matter what
| type of RADIUS you are using, intermediates always have access to the EAP
| MSK.  The difference between RADIUS/UDP and RADIUS/TLS or RADIUS/DTLS is the
| question of how much passive intermediaries are going to be able to see
| based on the use of a long term shared secret.

True indeed, slip up. Fixed in upcoming -01.

What does the list think of the use of RADIUS rather than AAA here?
Should we be more generic?


| Section 2.2 - Passive observers may also be able to fingerprint the client
| based on TLS restart information.

What does "TLS restart" mean in this context? Do you mean a RadSec
client re-establishing a torn down connection? Or maybe TLS
renegotiation?  Or, most probably, something third that I'm not familiar
with?


| Section 2.3 - This should include exposing the realm of the user (or the
| full user name in bad implementations).

Do you refer to the "Mechanism Name", as described in RFC7055 section
3.1. or is user realm (and possibly name) carried somewhere else?


| You say
| 
|    [ maybe expand on how TEAP [draft-ietf-emu-eap-tunnel-method
| <http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method> ] could
|    solve the problem of AAA proxies learning the MSK, impersonating the
|    RP ]
| 
| I would be very interested in seeing how you think there could possibly be a
| solution in this space.  I can't see one.

I will have to attend to this later.


| There probably needs to be a nod to using an application level tunnel as
| well.  While I think that it might be nice to have this in the GSS-EAP
| layer, we cannot ignore this as an option.

Good idea.