Question on HS20, possibly realm related.

[Ben Greear]

On 09/23/2013 01:33 AM, Jouni Malinen wrote:
> On Thu, Sep 19, 2013 at 03:43:11PM -0700, Ben Greear wrote:
>
>> I notice something that seems strange to me.  If I don't configure a user-name in
>> supplicant, it will not attempt to connect to the AP, but it does not actually matter
>> what I choose for the user-name..it just needs to exist.
>
> username is used to determine which cred blocks are valid for comparing
> against NAI Realm list.

Can you point me to that code or provide more details?  I tested with
my related RFC patch, and it would 'connect' to AP w/out username,
but it would fail the EAP response due to not finding identiy
and thus could not ever manage to actually send/receive useful data.

>> cred={
>>      username="client"
>>      password="lanforge"
>>      ca_cert="/home/lanforge/ca.pem"
>>      private_key="/home/lanforge/client.p12"
>>      private_key_passwd="lanforge"
>>      realm="lanforge.org"
>>      domain="lanforge.org"
>>      eap=TLS
>>
>> }
>
> That password entry looks pointless for EAP-TLS..

Yes, I've fixed that since posting the original email.

>> But, if I remove that 'username="client"', the interworking code will fail its EAP selection.
>>
>> If I change 'client' to anything else, it still works...so it does not actually seem to be
>> using that field for anything useful...
>
> Well, it will be used for building the EAP-Identity/Response value.
> There is currently no mechanism to build that automatically based on
> some client certificate fields, but if such code were to be added, it
> should be fine to ignore missing username for EAP-TLS case (but
> obviously not for other EAP types) in Interworking network selecting.

Since nothing actually seems to care about the name with EAP-TLS, can
we just hard-code some fallback value if user has not configured anything?

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com