> -----Original Message----- > From: abfab [mailto:[email protected]] On Behalf Of Linus Nordberg > Sent: Monday, February 24, 2014 9:41 AM > To: Jim Schaad > Cc: [email protected]; [email protected] > Subject: Re: [abfab] Comments on draft-linus-abfab-ephemeral-keying-00 > > Jim, thanks for the comments and sorry for the delay. Things have improved > for me since last week w.r.t. responsiveness. > > "Jim Schaad" <[email protected]> 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?
Something else - TLS Session Resumption using server State or PAC (see sections 3.2.1 and 3.2.2 of draft-ietf-emu-eap-tunnel-method) > > > | 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? I was referring to exposing the user name, for those cases where people don't either tunnel it or don't truncate it to just the realm in the initial EAP message sent to the acceptor. Jim > > > | 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. > > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
