User-Name return glitch in FR 3.0.17?

Tue Apr 24 13:29:38 CEST 2018

>     The debug log you posted shows no User-Name in the session-state list.

Eh? Sorry Alan, but it does have one! See the quoted bits:

(6)         update {
>> (6)           &outer.session-state::EAP-Channel-Binding-Message += &reply:EAP-Channel-Binding-Message[*] -> 0x02002a01a40648545450a524736572766963652e6d6f6f6e73686f742d706c617970656e2e74692e6a612e6e6574
>> (6)           &outer.session-state::Reply-Message += &reply:Reply-Message[*] -> 'Bob has authenticated'
>> (6)           &outer.session-state::User-Name += &reply:User-Name[*] -> 'root'
>> (6)         } # update = noop
(6)       } # if (1)  = noop
(6)     } # post-auth = noop
(6) } # server inner-tunnel
(6) Virtual server sending reply
(6)   EAP-Channel-Binding-Message = 0x02002a01a40648545450a524736572766963652e6d6f6f6e73686f742d706c617970656e2e74692e6a612e6e6574
>> (6)   Reply-Message = "Bob has authenticated"
>> (6)   User-Name = "root"
(6) eap_ttls: Got tunneled Access-Accept
(6) eap_ttls: Sending tunneled reply attributes
(6) eap_ttls:   EAP-Channel-Binding-Message = 0x02002a01a40648545450a524736572766963652e6d6f6f6e73686f742d706c617970656e2e74692e6a612e6e6574
(6) eap: Sending EAP Request (code 1) ID 7 length 99
(6) eap: EAP session adding &reply:State = 0x99ee34c09fe92160
(6)     [eap] = handled
(6)   } # authenticate = handled
(6) Using Post-Auth-Type Challenge
(6) Post-Auth-Type sub-section not found.  Ignoring.
(6) # Executing group from file /etc/raddb/sites-enabled/abfab-tr-idp
>> (6) session-state: Saving cached attributes
(6)   Moonshot-Host-TargetedId := "33127397-1bb6-5e95-8859-dfe76acfba67 at idp.test.assent"
(6)   Moonshot-Realm-TargetedId := "abd0d71b-7294-5423-86b1-3fae0bd7b33a at idp.test.assent"
(6)   Moonshot-TR-COI-TargetedId := "b40d0def-5b25-52bd-8d13-e6d22fa24648 at idp.test.assent"
(6)   EAP-Channel-Binding-Message += 0x02002a01a40648545450a524736572766963652e6d6f6f6e73686f742d706c617970656e2e74692e6a612e6e6574
>> (6)   Reply-Message += "Bob has authenticated"
>> (6)   User-Name += "root"
(6) Sent Access-Challenge Id 189 from 0.0.0.0:2083 to 13.94.115.212:48186 length 0
:
:
(7) Restoring &session-state
(7)   &session-state:Moonshot-Host-TargetedId := "33127397-1bb6-5e95-8859-dfe76acfba67 at idp.test.assent"
(7)   &session-state:Moonshot-Realm-TargetedId := "abd0d71b-7294-5423-86b1-3fae0bd7b33a at idp.test.assent"
(7)   &session-state:Moonshot-TR-COI-TargetedId := "b40d0def-5b25-52bd-8d13-e6d22fa24648 at idp.test.assent"
(7)   &session-state:EAP-Channel-Binding-Message += 0x02002a01a40648545450a524736572766963652e6d6f6f6e73686f742d706c617970656e2e74692e6a612e6e6574
>> (7)   &session-state:Reply-Message += "Bob has authenticated"
>> (7)   &session-state:User-Name += "root"
:
:
(7) # Executing section post-auth from file /etc/raddb/sites-enabled/abfab-tr-idp
(7)   post-auth {
(7)     update {
(7)       &reply::Moonshot-Host-TargetedId += &session-state:Moonshot-Host-TargetedId[*] -> '33127397-1bb6-5e95-8859-dfe76acfba67 at idp.test.assent'
(7)       &reply::Moonshot-Realm-TargetedId += &session-state:Moonshot-Realm-TargetedId[*] -> 'abd0d71b-7294-5423-86b1-3fae0bd7b33a at idp.test.assent'
(7)       &reply::Moonshot-TR-COI-TargetedId += &session-state:Moonshot-TR-COI-TargetedId[*] -> 'b40d0def-5b25-52bd-8d13-e6d22fa24648 at idp.test.assent'
(7)       &reply::EAP-Channel-Binding-Message += &session-state:EAP-Channel-Binding-Message[*] -> 0x02002a01a40648545450a524736572766963652e6d6f6f6e73686f742d706c617970656e2e74692e6a612e6e6574
>> (7)       &reply::Reply-Message += &session-state:Reply-Message[*] -> 'Bob has authenticated'
>> (7)       &reply::User-Name += &session-state:User-Name[*] -> 'root'
(7)     } # update = noop
:
:
(7) Sent Access-Accept Id 83 from 0.0.0.0:2083 to 13.94.115.212:48186 length 0
(7)   MS-MPPE-Recv-Key = 0x1ee8bbd31cd79fd4e98d946e946e1f976b7aaebd6e5412b4bab51b2e2d784c9c
(7)   MS-MPPE-Send-Key = 0x4de6d0ddcf7a725afc0a7e4b7fb2478b5c59a76ac5689342d33fbcdb4787f2c7
(7)   EAP-Message = 0x03070004
(7)   Message-Authenticator = 0x00000000000000000000000000000000
>> (7)   User-Name = "@idp.test.assent"
(7)   Proxy-State = 0x30
(7)   Moonshot-Host-TargetedId += "33127397-1bb6-5e95-8859-dfe76acfba67 at idp.test.assent"
(7)   Moonshot-Realm-TargetedId += "abd0d71b-7294-5423-86b1-3fae0bd7b33a at idp.test.assent"
(7)   Moonshot-TR-COI-TargetedId += "b40d0def-5b25-52bd-8d13-e6d22fa24648 at idp.test.assent"
(7)   EAP-Channel-Binding-Message += 0x02002a01a40648545450a524736572766963652e6d6f6f6e73686f742d706c617970656e2e74692e6a612e6e6574
>> (7)   User-Name += "root"

This is the problem. There are *two* User-Name attributes now. 'root' came from the inner-tunnel as expected. The User-Name of '@idp.test.assent' is unexpected.

>     Hmm... if I set the inner reply with a User-Name, and then set "use_tunneled_reply = yes", then the inner User-Name is copied to the outer one as expected.

use_tunneled_reply is deprecated. We're using the 'new' way, using the session-state list.

I've uploaded a set of files to https://www.dropbox.com/sh/tonkqtbxloyzb8d/AAAUWbTS1xzvsnPWY9gk6KR2a?dl=0

What you'll find there is a folder called 'fr3015-3017-username-glitches', in which you have 5 runs of exactly the same authentication set (and a compressed archive of all runs):

1. A run in FR 3.0.15, all three actors (APC, IDP and RP) in the correct 'default' state:
 - fr3015-apclog-apc-default-rp-default-idp-default
 - fr3015-idplog-apc-default-rp-default-idp-default
 - fr3015-rplog-apc-default-rp-default-idp-default

This state shows a complete successful authentication run. It returns as part of the Access-Accept from the IdP to the RP the User-Name value of 'root'. That is overwritten on the RP to 'moonshot'. To see which packets go where at what time, see the logs in the 'fr3015-with-ts' folder, which were run with the -fxxx parameter but the date (not time) and 'Debug' and 'Info' messages removed.

2. A run in FR 3.0.17, all three actors (APC, IDP and RP) in the correct 'default' state (as upgraded to from 3.0.15):
 - fr3017-apclog-apc-default-rp-default-idp-default
 - fr3017-idplog-apc-default-rp-default-idp-default
 - fr3017-rplog-apc-default-rp-default-idp-default

Here you will only find APC and RP interacting. Because APC returns *two* User-Name attributes ('@test.assent' and the real value), the whole flow fails.

3. A run in FR 3.0.17, the APC modified, IDP and RP in 'default' state:
 - fr3017-apclog-apc-mod-rp-default-idp-default
 - fr3017-idplog-apc-mod-rp-default-idp-default
 - fr3017-rplog-apc-mod-rp-default-idp-default

Here you will find a complete successful authentication run. The APC has been modified with the 'update reply {...}' fix in post-auth. However, IDP returns *two* User-Name attributes ('@idp.test.assent' and the value 'root'), and the RP rewrites the first to 'moonshot'.

4. A run in FR 3.0.17, the APC and RP modified, IDP in 'default' state:

 - fr3017-apclog-apc-mod-rp-mod-idp-default
 - fr3017-idplog-apc-mod-rp-mod-idp-default
 - fr3017-rplog-apc-mod-rp-mod-idp-default

Here you will find a complete successful authentication run. The APC and RP have been modified with the 'update reply {...}' fix in post-auth. However, IDP returns *two* User-Name attributes ('@idp.test.assent' and the value 'root'), the RP deletes *all* instances of User-Name and sets one of 'moonshot'.

5. A run in FR 3.0.17, all three actors (APC, IDP and RP) modified:

 - fr3017-apclog-apc-mod-rp-mod-idp-mod
 - fr3017-idplog-apc-mod-rp-mod-idp-mod
 - fr3017-rplog-apc-mod-rp-mod-idp-mod

Here you will find a failure again, because the IDP deletes the User-Name that is necessary for the APC to authorize a connection. The flow fails, the RP retries and eventually has to give up.

What I *would* expect is to see the flow in FR 3.0.15 in FR 3.0.17.

I hope this helps.

With Regards

Stefan Paetow
Consultant, Trust and Identity

t: +44 (0)1235 822 125
gpg: 0x3FCE5142
xmpp: stefanp at jabber.dev.ja.net
skype: stefan.paetow.janet

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20180424/1dd74152/attachment.sig>