3.0.x: Session resumption and CUI calculation
Hello, so, now that session resumption works, there seems to be an error in the calculation of Chargeable-User-Identity in the *reauth* of tunneled methods (tried PEAP). Here is a full -Xxx debug log to show the xlat parser sequence: http://pastebin.com/4N5zYJXw The input in both the auth and re-auth is an Access-Request with Operator-Name = "1restena.lu" Chargeable-User-Identity=\0 User-Name (outer) = "availability-test@education.lu" In phase 2 during auth, the actual inner User-Name is then "test.eduroam@education.lu". This is correctly memorised by the session cache logic. At first auth: The (default) salt "changeme", the inner User-Name and the Operator-Name value trigger the calculation and returning of CUI. The calculated value is Chargeable-User-Identity = '5a91e08fc9760dca96a311ccb333e2b8737ad600' which I think is correct. During re-auth, I see the line: eap_peap : Adding cached attributes for session 8443da65e46717de420e76b52167eced7712da034f9cee7bef1cffb899a7209d: User-Name = 'test.eduroam@education.lu' so during reauth time, the username to be used is known prior to the calculation of the reauth CUI. And yet: expand: "%{sha1:changeme%{tolower:%{User-Name}}%{%{Operator-Name}:-}}" -> 'ad40aca101096cde0ce27b387939e4c76d8234ca' This is not what one needs. I suspect that this construct uses the request:User-Name (availability-test@education.lu) instead of the retrieved session's (test.eduroam@education.lu). I wonder how to correctly reference the "inner" User-Name. Since there is no phase 2 (but a fake attribute list for that phase 2) would inner.User-Name work? Or use reply:User-Name explicitly? One of those two should fix the situation if writing "%{sha1:changeme%{tolower:%{%{reply:User-Name}:-%{User-Name}}}%{%{Operator-Name}:-}}" The reply (or maybe inner) part of it would work for the retrieved fake phase2 id, and for methods with no tunnel at all (say EAP-TLS) it would get expanded to the normal User-Name as before. Is my argumentation sound? And the fix reasonable? 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 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On 11 Feb 2014, at 08:36, Stefan Winter <stefan.winter@restena.lu> wrote:
Hello,
so, now that session resumption works, there seems to be an error in the calculation of Chargeable-User-Identity in the *reauth* of tunneled methods (tried PEAP).
Here is a full -Xxx debug log to show the xlat parser sequence:
The input in both the auth and re-auth is an Access-Request with Operator-Name = "1restena.lu" Chargeable-User-Identity=\0 User-Name (outer) = "availability-test@education.lu"
In phase 2 during auth, the actual inner User-Name is then "test.eduroam@education.lu". This is correctly memorised by the session cache logic.
At first auth:
The (default) salt "changeme", the inner User-Name and the Operator-Name value trigger the calculation and returning of CUI. The calculated value is
Chargeable-User-Identity = '5a91e08fc9760dca96a311ccb333e2b8737ad600'
which I think is correct.
During re-auth, I see the line:
eap_peap : Adding cached attributes for session 8443da65e46717de420e76b52167eced7712da034f9cee7bef1cffb899a7209d: User-Name = 'test.eduroam@education.lu'
so during reauth time, the username to be used is known prior to the calculation of the reauth CUI.
And yet:
expand: "%{sha1:changeme%{tolower:%{User-Name}}%{%{Operator-Name}:-}}" -> 'ad40aca101096cde0ce27b387939e4c76d8234ca'
This is not what one needs.
I suspect that this construct uses the request:User-Name (availability-test@education.lu) instead of the retrieved session's (test.eduroam@education.lu).
I wonder how to correctly reference the "inner" User-Name. Since there is no phase 2 (but a fake attribute list for that phase 2) would inner.User-Name work? Or use reply:User-Name explicitly?
One of those two should fix the situation if writing
"%{sha1:changeme%{tolower:%{%{reply:User-Name}:-%{User-Name}}}%{%{Operator-Name}:-}}"
The reply (or maybe inner) part of it would work for the retrieved fake phase2 id, and for methods with no tunnel at all (say EAP-TLS) it would get expanded to the normal User-Name as before.
Is my argumentation sound? And the fix reasonable?
I don’t recalculate the CUI for cached sessions, instead I store the CUI in the cache: In the outer post-auth: if ( reply:Cached-Session-Policy ) { # # retrieve CUI for cached session (else to cache) # if ( reply:Cached-Session-Policy =~ /cui=(.+)/ ) { update reply { Reply-Message += "Cached policy: %{reply:Cached-Session-Policy}" Chargeable-User-Identity := "%{1}" } } elsif (reply:Chargeable-User-Identity) { update reply { Cached-Session-Policy := "cui=%{reply:Chargeable-User-Identity}" } } # # retrieve VLAN attribute for a resumed EAP Session # if ( reply:Cached-Session-Policy =~ /vlan=(.+)/ ) { update reply { Reply-Message += "Cached policy: %{reply:Cached-Session-Policy}" Tunnel-Private-Group-ID := "%{1}" Tunnel-Type = VLAN Tunnel-Medium-Type = IEEE-802 Session-Timeout = 28800 Termination-Action = RADIUS-Request } } } In the inner the Cached-session-policy is always created when the VLAN is assigned (by a perl script): ##################### # RETURN ATTRIBUTES # ##################### $RAD_REPLY{'Tunnel-Medium-Type'} = "IEEE-802"; $RAD_REPLY{'Tunnel-Type'} = "VLAN"; $RAD_REPLY{'Tunnel-Private-Group-Id'} = "$returnVlan"; # return vlan $RAD_REPLY{'Session-Timeout'} = "28800"; # 8 hours $RAD_REPLY{'Termination-Action'} = "RADIUS-Request"; # store return vlan in eap cache for # session resumption $RAD_REPLY{'Cached-Session-Policy'} = "vlan=$returnVlan"; return RLM_MODULE_UPDATED; Regards Scott
Stefan Winter wrote:
so, now that session resumption works, there seems to be an error in the calculation of Chargeable-User-Identity in the *reauth* of tunneled methods (tried PEAP).
Why re-calculate it? It should be cached and replayed from the cache. I'll add CUI to the cache. Ideally, the cache entries should be configurable. Patches are welcome. :)
so during reauth time, the username to be used is known prior to the calculation of the reauth CUI.
And yet:
expand: "%{sha1:changeme%{tolower:%{User-Name}}%{%{Operator-Name}:-}}" -> 'ad40aca101096cde0ce27b387939e4c76d8234ca'
This is not what one needs.
The debug output should show the expansion of the User-Name and Operator-Name. That will let you know what's going on.
I wonder how to correctly reference the "inner" User-Name. Since there is no phase 2 (but a fake attribute list for that phase 2) would inner.User-Name work? Or use reply:User-Name explicitly?
You'll have to copy the inner User-Name to the outer reply. Perhaps as another attribute.
One of those two should fix the situation if writing
"%{sha1:changeme%{tolower:%{%{reply:User-Name}:-%{User-Name}}}%{%{Operator-Name}:-}}"
The reply (or maybe inner) part of it would work for the retrieved fake phase2 id, and for methods with no tunnel at all (say EAP-TLS) it would get expanded to the normal User-Name as before.
Maybe.
Is my argumentation sound? And the fix reasonable?
If it works. Honestly, it's easier to just cache the CUI. Alan DeKok.
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Scott Armitage -
Stefan Winter