rlm_eap_tls: authenticate instead of authorize?

Alan DeKok aland at deployingradius.com
Tue Jan 10 13:27:10 CET 2012

Graham Leggett wrote:
> I notice that when rlm_eap_tls checks the user's certificate, it does so in the authenticate section instead of the authorize section,

  It does it when it decodes the EAP packet, and does the SSL stuff.
This is due to how the EAP module is designed.

> and in the process none of the fields in the certificate are available to other modules until post_auth.

  Yes, that's an issue.

> Would there be any ill effects if the rlm_eap_tls certificate parsing was moved from the authenticate section to the  authorize section?

  Likely not.  But the difficulty is doing that *only* for the EAP-TLS
code.  The EAP modules currently do all of their work in the
"authenticate" section, for good reason.  Nearly everything in EAP is
based on authentication.  So doing the work in another section would be

  e.g. EAP-MSCHAPv2 does it's work in the "authenticate" section,
because it authenticates users!

  In order for the EAP-TLS cert checking to be done in the "authorize"
section, a *lot* of code will need to change.  See
src/modules/rlm_eap/rlm_eap.c, eap_authorize() and eap_authenticate()

  Off of the top of my head, you'll have to:

- move the eap_vp2packet() code to the "authorize" section, and cache
the packet somewhere

- grab the handler in the "authorize" section.  See mem.c for more code.
  that code *also* assumes that getting the handler means removing it
  from the list.  That assumption may not be valid for "authorize"

- find the EAP type from the handler, and call the "authorize" function
  this is new code.  The EAP type struct contains an entry for
  "authorize", but no module implements "authorize"

- I'd say change EAP-MD5 to send challenges in the "authorize" section
  this lets you do testing without using complex TLS code

- hack the TLS code to do certificate checking in the "authorize"

- If the certificate fails validation, what do you do?  Is this
  a reject, or is the reject delayed until the "authenticate"

- test EAP-TLS, PEAP, and TTLS with/without client certs

  If you're going down this path, use github.  Do the work in a series
of small patches, as above.  Send push requests which massage the code,
but don't break anything.  Jumbo patches containing 1000's of lines of
changed code will be ignored.

  Oh, and this has to go into the "master" branch instead of the v2.1.x
branch.  v2.1.x is a "stable" branch.  Making massive changes to it
means de-stabilizing the server, which can't be done.

  Alan DeKok.

More information about the Freeradius-Users mailing list