3.0.x: Session resumption and CUI calculation

[Stefan Winter]

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 at education.lu"

In phase 2 during auth, the actual inner User-Name is then
"test.eduroam at 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 at 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 at education.lu) instead of the retrieved session's
(test.eduroam at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x8A39DC66.asc
Type: application/pgp-keys
Size: 3243 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20140211/795687dd/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20140211/795687dd/attachment.pgp>