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

From: "Jim Schaad" <[email-masked]>
Date: 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.  

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.

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

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

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.

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.

Jim

---

From: Linus Nordberg <[email-masked]>
Date: Mon, 24 Feb 2014 17:41:13 +0000

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-masked]> 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.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 24 Feb 2014 09:12:32 -0800

> -----Original Message-----
> From: abfab [mailto:[email-masked]] On Behalf Of Linus Nordberg
> Sent: Monday, February 24, 2014 9:41 AM
> To: Jim Schaad
> Cc: [email-masked]; [email-masked]
> 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-masked]> 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.
> 
and
> acceptor is not enough in this section even if the suggested solution is
limited
> to adding additional encryption to that stretch.
> 
> 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.
> | 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.
> 
> | 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

> | I would be very interested in seeing how you think there could
> | possibly be a solution in this space.  I can't see one.
> 
> | 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-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Linus Nordberg <[email-masked]>
Date: Tue, 25 Feb 2014 15:34:41 +0000

"Jim Schaad" <[email-masked]> wrote
Mon, 24 Feb 2014 09:12:32 -0800:

| > | 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)

Good point. I added the following to upcoming -01.

--8<---------------cut here---------------start------------->8---
In cases where a TLS-based EAP method is used, a passive observer may
be able to fingerprint the client based on TLS session resumption, for
example as described in {{RFC5077}} section 5.8.
--8<---------------cut here---------------end--------------->8---

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

This is mentioned in 2.1. One could indeed argue that it should go here
instead, or both there and here.

| > |    [ 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 still haven't worked this through really. Please let me know what's
wrong with the following sketch.

If an EAP peer and server (i.e. ABFAB client and IdP) establish a TLS
session using TEAP with a DHE key exchange, they will share an ephemeral
key which is not known to any intermediaries. The question is how peer
and server authenticate each other. In an ABFAB setting, client and IdP
share a secret in the user pass phrase and can use that as a PSK using a
TLS_DHE_PSK cipher suite.

An alternative authentication method might be TEAP password
authentication (Basic-Password-Auth-Req/Resp). Unless it isn't.

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

What about something like this, as an addition to section 3.1.?

--8<---------------cut here---------------start------------->8---
An alternative place to protect ABFAB authentication with a short
lived key would be in the application level protocol. While some
applications are using protocols already able to protect the GSS-API
traffic using a TLS session with an ephemeral key (XMPP, IMAP, SMTP)
it's not mandatory to use such a tunnel. Other applications use
protocols which might be hard to protect in a tunnel (NFS, SSH).
--8<---------------cut here---------------end--------------->8---