Re: Action to perform when EAP/TLS has finished successfully

[Artur Hecker]

hi Andreas


>> well, i don't know why you need 4-5 queries but supposing you need
>> them, why would you need less later on? where is the difference
>> whether you do the db query before or later, that's what i don't
>> catch. and the increase of the counter, what you want to do in case
>> of success is a completely different task (complementary if you
>> want, but contradictory in the sense that you can not combine the
>> db-queries anyway).
>>
>> do you misunderstand you?
>
>
> I think yes.

i meant of course, if I misunderstood you :) sorry


> From the RADIUS packet perpsective, EAP/TLS does not simply mean
> *one* Access-Request and *one* ACCESS-ACCEPT per authentication
> attempt. Furthermore Radius-Packets (requests, challenges) are used
> to tranport the TLS PDUs, which are exchanged between the RADIUS and
> the supplicant and it is my observation, that 4-5 Radius access
> requests and a correpsonding number of challenges are needed in order
> to complete a TLS authentication. This exactly causes my problem,
> since I don't want to to my additional stuff fore each of these
> requests, but only once.

oh i'm perfectly aware of this. it's even quite right in the current praxis, however theoretically this value can differ considerably depending on the used hardware and PKI and in particular be very much higher. EAP/TLS performs fragmentation on the link layer level, i.e. depending on the available MAC-MTU and the payload. the MAC-MTU can change depending on the used network technology; even if it is very unlikely, a single X.509 certificate can be up to 16MB big. simultaneously, every single EAP/TLS frame is simply handed over to the radius server resulting in the number of radius packets corresponding exactly to the sent eap packets on the link to be authenticated minus two (eap start is not sent over - but could be if i remember correctly - and the eap-key message happens after the auth).

i'm not sure that above i explained correctly what you could do. you can act on the FIRST packet received, not the last. it doesn't matter if there will be 1000 or only 4 packets, the first packet is simply to recognize because it is the only one to contain EAP response identity information. you simply have to parse the EAP-Message attribute. later on all requests will contain TLS exchanges or TLS start or TLS ACKs.


> I've access to attribute split in check and reply items. Since these
> are presented in a hash, I only see the last instance of e.g. the TLS
> messages, in case this attribute appears more than once. I've hacket
> in a workaround for that, but having acccess to the TLS message does
> not really help me further, since so far as I understood it, I'd need
> to follow a whole conversation on TLS level, since the part I'm
> interested in is already encrypted and this sound rather complicated
> to me.

yepp, don't touch TLS. simply see if it is an ACCEPT or something else. you certainly know what kind of message it is.


ciao
artur


--
Artur Hecker
Département Informatique et Réseaux, ENST Paris
http://www.infres.enst.fr/~hecker


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html