use_tunneled_reply has no effect
I have searched through the maillinglist archive regarding this matter. There was one thread similar to the problem I'm facing with: Have the outer-tunnel reply with the user-name specified in the inner-tunnel; thus instead of anonymous@some.realm
From this thread: http://lists.freeradius.org/mailman/htdig/freeradius-users/2005-June/msg0057...
In eap.conf: ttls { .... use_tunneled_reply = yes virtual_server = "inner-tunnel" } In users: .... DEFAULT User-Name = "%{User-Name}", Fall-Through = no Running radiusd in debug mode, the User-Name attribute remained unchanged through out the request session. Best regards, Xiwen --
I have searched through the maillinglist archive regarding this matter. There was one thread similar to the problem I'm facing with: Have the outer-tunnel reply with the user-name specified in the inner-tunnel; thus instead of anonymous@some.realm
From this thread: http://lists.freeradius.org/mailman/htdig/freeradius-users/2005-June/msg0057...
In eap.conf: ttls { .... use_tunneled_reply = yes virtual_server = "inner-tunnel" }
In users: .... DEFAULT User-Name = "%{User-Name}", Fall-Through = no
Running radiusd in debug mode, the User-Name attribute remained unchanged through out the request session.
This is already present in post-auth in latest version (after a lengthy explanation): #update outer.reply { # User-Name = "%{request:User-Name}" #} Just remove comments. Ivan Kalik Kalik Informatika ISP
On Wed, Jun 17, 2009 at 10:48:07AM +0100, Ivan Kalik wrote:
This is already present in post-auth in latest version (after a lengthy explanation):
#update outer.reply { # User-Name = "%{request:User-Name}" #}
After uncommenting that in inner-tunnel, I see local users authenticated by the LOCAL auth called outer.reply. But this is not the case for external users(Realm handled by external proxy). The latter is what I really want: being able to see which external user is authenticating. As we are not doing Accounting, isn't it possible to move the outer.reply higher up in the stack? Or it shouldn't matter? Kind regards, xiwen --
Hi,
After uncommenting that in inner-tunnel, I see local users authenticated by the LOCAL auth called outer.reply. But this is not the case for external users(Realm handled by external proxy).
The latter is what I really want: being able to see which external user is authenticating.
The whole concept of inner tunneling and protecting it via TLS is *because* you are *not* supposed to see the actual authentication credentials. For your local users, you terminate the tunnel yourself and can decide to expose the information by uncommenting the above, but for non-local users it is supposed to not work.
As we are not doing Accounting, isn't it possible to move the outer.reply higher up in the stack? Or it shouldn't matter?
Outer anonymous identities preserve privacy of the (remote) user authenticating. If you want to change that, you need a business agreement with the remote party to disclose their user information to you. Taking a peek at your mail domain name: if you are about to set up eduroam - there is no automated disclosure of the inner identity in eduroam. There is a process to ask the identity provider (IdP) retroactively *if and when* the user has done something wrong and needs to be traced. But there is no proactive information disclosure - or better put, it's in the discretion of the IdP to tell the rest of the world who his user is; unsurprisingly most IdPs opt not to do so, if for no other reason than to evade privacy and data protection laws. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
On Wed, Jun 17, 2009 at 01:23:57PM +0200, Stefan Winter wrote:
The whole concept of inner tunneling and protecting it via TLS is *because* you are *not* supposed to see the actual authentication credentials. For your local users, you terminate the tunnel yourself and can decide to expose the information by uncommenting the above, but for non-local users it is supposed to not work.
Outer anonymous identities preserve privacy of the (remote) user authenticating. If you want to change that, you need a business agreement with the remote party to disclose their user information to you.
Taking a peek at your mail domain name: if you are about to set up eduroam - there is no automated disclosure of the inner identity in eduroam. There is a process to ask the identity provider (IdP) retroactively *if and when* the user has done something wrong and needs to be traced. But there is no proactive information disclosure - or better put, it's in the discretion of the IdP to tell the rest of the world who his user is; unsurprisingly most IdPs opt not to do so, if for no other reason than to evade privacy and data protection laws.
Yes, I am aware privacy is a concern. As I am doing some tests, I thought it would be easier to debug if there's a way to relate a request to a proxied username. This is technically not possible or it's more a political matter? I thought the outer-tunnel is set up to secure the connection between the user and the authentication server. So the Authentication has access to the unencrypted data which it in turn queries proxies to verify the received credentials; this data is encrypted using the home-server shared key. Please enlighten me if this is not correct. Best regards, Xiwen --
Hi,
I thought the outer-tunnel is set up to secure the connection between the user and the authentication server. So the Authentication has access to the unencrypted data which it in turn queries proxies to verify the received credentials; this data is encrypted using the home-server shared key. Please enlighten me if this is not correct.
the outer identity is used to identity (and can be anonymous - the RFC states it should be blank ie @realm.com rather than anonymous@realm.com) the user that is requesting the service - so that the packets can be sent to the correct end server via proxy methods before the inner tunnel can be created (which uses the RADIUS certificate etc to create a secure tunnel through the proxied path) authentication can never occur on outer id/outer tunnel. well, it could if you just didnt care about security, didnt use passwords and didnt have any kind of EAP ;-) dont forget, the user never does anything. the packets get sent via 802.1X to the NAS (RADIUS client) which in turn passes the RADIUS packets to the RADIUS server (which then proxies etc if needed). the NAS will never talk directly to the final AAA RADIUS - the communication is always passed through the proxy chain. alan
Hi,
Yes, I am aware privacy is a concern. As I am doing some tests, I thought it would be easier to debug if there's a way to relate a request to a proxied username. This is technically not possible or it's more a political matter?
Technically impossible until you break TLS. OR make a deal with the home server that it reveals the actual user name to you.
I thought the outer-tunnel is set up to secure the connection between the user and the authentication server.
And the *home* authentication server. If you operate a proxy in the middle between user and home server, you will not see the inner tunnel credentials.
So the Authentication has access to the unencrypted data which it in turn queries proxies to verify the received credentials;
Only the *home* authentication server has access to the credentials. These credentials are typically not proxied anywhere (there are exceptions at the discretion of that home server).
this data is encrypted using the home-server shared key. Please enlighten me if this is not correct.
The shared secret ensures packet integrity between RADIUS peers, i.e. between your proxy and the home server. With EAP authentication, it does *not* add anything to credential encryption - that happens entirely in the EAP tunnel. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
On Thu, Jun 18, 2009 at 08:30:27AM +0200, Stefan Winter wrote:
Hi,
Yes, I am aware privacy is a concern. As I am doing some tests, I thought it would be easier to debug if there's a way to relate a request to a proxied username. This is technically not possible or it's more a political matter?
Technically impossible until you break TLS. OR make a deal with the home server that it reveals the actual user name to you.
I thought the outer-tunnel is set up to secure the connection between the user and the authentication server.
And the *home* authentication server. If you operate a proxy in the middle between user and home server, you will not see the inner tunnel credentials.
So the Authentication has access to the unencrypted data which it in turn queries proxies to verify the received credentials;
Only the *home* authentication server has access to the credentials. These credentials are typically not proxied anywhere (there are exceptions at the discretion of that home server).
this data is encrypted using the home-server shared key. Please enlighten me if this is not correct.
The shared secret ensures packet integrity between RADIUS peers, i.e. between your proxy and the home server. With EAP authentication, it does *not* add anything to credential encryption - that happens entirely in the EAP tunnel.
Thanks for the clarifications. Cheers, Xiwen --
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Ivan Kalik -
Stefan Winter -
Xiwen Cheng