Re: Issue 63: Request-ID Supplementation

[Bernard Aboba <aboba@internaut.com>]

> Not in FreeRADIUS.  Our implementation does not track EAP
> identifiers by NAS-IP-Address or other attribute sent by the NAS.
> Instead, it uses the EAP identifier, source IP address, and the State
> attribute.  Since the State attribute is under the control of the
> RADIUS server, this means that the "uniqueness" of each session is
> under the control of the server, and not the NAS.
>
>   Since proxies may play games with NAS-IP-Address (e.g. translating
> private IP's to their own), depending on any attribute under control
> of the NAS may result in deployment problems.

I think this meets the requirements of RFC 3579.  The goal was for a
RADIUS server to be able to distinguish between EAP sessions regardless of
which NAS they came from.

>   A rough description of the algorithm used is as follows:
>
>   if (EAP start, or EAP identity) {
>      allocate unique State Attribute
>      insert into "active" queue, with key (EAP identifier, State, source IP)
>   } else {
>      look up active session in queue, with above key
>   }
>
>   The algorithm appears to work in deployment, including home servers
> which receive EAP sessions via intermediate RADIUS proxies.
>
> > Is it sufficient to address the Request-ID number space
> > "wrap-around" issue?
>
>   For RADIUS Request ID's?  I'm unclear.

The RADIUS Request-ID shouldn't affect this algorithm.  However, once the
Request-ID wraps you've got potentially more serious problems since the
key stream used in encrypting "hidden" RADIUS attributes should be
considered compromised.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>