[First, I'm a newcomer to this list. If this was already answered
before (although I search through the archives before posting) please
appologize and point me to the appropriate resorce]
Dear all,
Here's "yet another new bee biting the EAP-TLS dust" (tm).
My set-up:
- Authenticating server:
* Debian/Unstable w. 2.6.5 vanilla kernel
* freeradius-snapshot-20040513
* openssl-0.9.7-stable-SNAP-20040513.
Side note: Stock Debian "openssl", "libssl" and "libssl-dev" packages
were removed i.e. this is the only SSL on my system (in case you'd ask).
- Authenticator: Ethernet switch Netgear FSM 726S with 2.3.2
firmware. For the purpose of this mail it has the IP addie 192.168.0.1
and hostname "netgear-switch.domain.com"
- Supplicant: WinXP Pro. SP1 + usual cruft.
Documentation Sources:
[1] "FreeRADIUS/WinXP Authentication Setup" from
http://www.dslreports.com/forum/remark,9286052~mode=flat
[2] "FreeRADIUS EAP/TLS - WinXP HOWTO" from
http://www.impossiblereflex.com/8021x/eap-tls-HOWTO.htm
My problem:
After following the EAP-TLS mantra at [1], generating certificates
and installing them successfully (AFAICT) EAP-TLS doesn't work. After
carefully combing through the logs and comparing w/ the ones given
[2] it seems that the EAP-TLS authentication doesn't succeed as I do
not even reach the TLS handshake phase: The only thing the
(freeradius) server does is it receives "Access-Request", answers
back w/ an "Access-Challenge", receives a new "Accesss-Request" to
which it answers w/ a new "Access-Challenge", and so on, in an
infinite loop, with no TLS establish and no EAP transaction peformed
beyond the above steps.
At the end of this mail I'll attach a sever debug output (the
output is cropped for bervity purposes to leave only the relevant parts.
Of course the full monty is avail on request ;).
My questions:
1) All "Access-Challenge" messages rightfully (?) have the same "id"
as the triggering "Access-Request". However, the latter are
non-sequential. If this is supposed to be a 3-way handshake of sorts
(is it ?) than in response to the server's "Access-Challenge" I
should get an "Access-Request" with the "id" incremented ?
In other words, how do I get to distiguish btw. new "Access-Requests" and
the ones that should (??) come in response to server's own "Access-Challenge" ?
The reason I'm asking is that in the logs at [2] the second "Access-Request"
received from the client has an "id" incremented w.r.t previous one,
making me suspecting that this is how the server detects the previous request
and consequently reports in the log:
[...]
rlm_eap: Request found, released from the list.
[...]
OTOH in my own server logs I never find smth similar.
2) After processing each "Access-Request", my server always reports:
[...]
rlm_eap: EAP Identity
rlm_eap: processing type tls
rlm_eap_tls: Requiring client certificate
rlm_eap_tls: Initiate
rlm_eap_tls: Start returned 1
[...]
but never any TLS handske appears to be starting.
IAny idea what/where to look for ?
Thanks for any help and/or pointers to relevent info,
Florian
P.S. Here is the server log describing message exchange. I left aside
the blurb printed out by the server before the "Listening on ports..."
line (there's no suspicious message there anyways). IP
addies/hostnames changed to "protect the innocent" :)
[...]
Starting - reading configuration files ...
<trimmed >
Listening on authentication *:1812
Listening on accounting *:1813
Listening on proxy *:1814
Ready to process requests.
rad_recv: Access-Request packet from host 192.168.0.1:1027, id=1, length=167
User-Name = "802.1x client (i.e. supplicant)"
NAS-IP-Address = 192.168.0.1
NAS-Port = 1
State = 0x300257fa5ecadec2b33ab1cc00d55927
NAS-Identifier = "netgear-switch.domain.com"
NAS-Port-Type = Ethernet
EAP-Message =
0x02010024013830322e317820636c69656e742028692e652e20737570706c6963616e7429
Message-Authenticator = 0x1f90d93abedd0aa9c21f7e1c7e3d7ba0
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 0
modcall[authorize]: module "preprocess" returns ok for request 0
modcall[authorize]: module "chap" returns noop for request 0
modcall[authorize]: module "mschap" returns noop for request 0
rlm_realm: No '@' in User-Name = "802.1x client (i.e. supplicant)", looking up
realm NULL
rlm_realm: No such realm "NULL"
modcall[authorize]: module "suffix" returns noop for request 0
rlm_eap: EAP packet type response id 1 length 36
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module "eap" returns updated for request 0
users: Matched 802.1x client (i.e. supplicant) at 65
modcall[authorize]: module "files" returns ok for request 0
modcall: group authorize returns updated for request 0
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 0
rlm_eap: EAP Identity
rlm_eap: processing type tls
rlm_eap_tls: Requiring client certificate
rlm_eap_tls: Initiate
rlm_eap_tls: Start returned 1
modcall[authenticate]: module "eap" returns handled for request 0
modcall: group authenticate returns handled for request 0
Sending Access-Challenge of id 1 to 192.168.0.1:1027
EAP-Message = 0x010200060d20
Message-Authenticator = 0x00000000000000000000000000000000
State = 0x300257fa5ecadec2d8b4b19c39257dbc
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 6 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 1 with timestamp 40a8bdd8
Nothing to do. Sleeping until we see a request.
rad_recv: Access-Request packet from host 192.168.0.1:1028, id=4, length=149
User-Name = "802.1x client (i.e. supplicant)"
NAS-IP-Address = 192.168.0.1
NAS-Port = 1
NAS-Identifier = "netgear-switch.domain.com"
NAS-Port-Type = Ethernet
EAP-Message =
0x02040024013830322e317820636c69656e742028692e652e20737570706c6963616e7429
Message-Authenticator = 0x80fb70a84b04a49a6b73fff351374948
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 1
modcall[authorize]: module "preprocess" returns ok for request 1
modcall[authorize]: module "chap" returns noop for request 1
modcall[authorize]: module "mschap" returns noop for request 1
rlm_realm: No '@' in User-Name = "802.1x client (i.e. supplicant)", looking up
realm NULL
rlm_realm: No such realm "NULL"
modcall[authorize]: module "suffix" returns noop for request 1
rlm_eap: EAP packet type response id 4 length 36
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module "eap" returns updated for request 1
users: Matched 802.1x client (i.e. supplicant) at 65
modcall[authorize]: module "files" returns ok for request 1
modcall: group authorize returns updated for request 1
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 1
rlm_eap: EAP Identity
rlm_eap: processing type tls
rlm_eap_tls: Requiring client certificate
rlm_eap_tls: Initiate
rlm_eap_tls: Start returned 1
modcall[authenticate]: module "eap" returns handled for request 1
modcall: group authenticate returns handled for request 1
Sending Access-Challenge of id 4 to 192.168.0.1:1028
EAP-Message = 0x010500060d20
Message-Authenticator = 0x00000000000000000000000000000000
State = 0xdc43108973cf13e5b8040cd7af21e587
Finished request 1
Going to the next request
--- Walking the entire request list ---
Waking up in 6 seconds...
--- Walking the entire request list ---
Cleaning up request 1 ID 4 with timestamp 40a8bdf6
Nothing to do. Sleeping until we see a request.
rad_recv: Access-Request packet from host 192.168.0.1:1029, id=6, length=149
User-Name = "802.1x client (i.e. supplicant)"
NAS-IP-Address = 192.168.0.1
NAS-Port = 1
NAS-Identifier = "netgear-switch.domain.com"
NAS-Port-Type = Ethernet
EAP-Message =
0x02060024013830322e317820636c69656e742028692e652e20737570706c6963616e7429
Message-Authenticator = 0xce799670b6b88832fe175ba83b5bc6db
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 2
modcall[authorize]: module "preprocess" returns ok for request 2
modcall[authorize]: module "chap" returns noop for request 2
modcall[authorize]: module "mschap" returns noop for request 2
rlm_realm: No '@' in User-Name = "802.1x client (i.e. supplicant)", looking up
realm NULL
rlm_realm: No such realm "NULL"
modcall[authorize]: module "suffix" returns noop for request 2
rlm_eap: EAP packet type response id 6 length 36
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module "eap" returns updated for request 2
users: Matched 802.1x client (i.e. supplicant) at 65
modcall[authorize]: module "files" returns ok for request 2
modcall: group authorize returns updated for request 2
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 2
rlm_eap: EAP Identity
rlm_eap: processing type tls
rlm_eap_tls: Requiring client certificate
rlm_eap_tls: Initiate
rlm_eap_tls: Start returned 1
modcall[authenticate]: module "eap" returns handled for request 2
modcall: group authenticate returns handled for request 2
Sending Access-Challenge of id 6 to 192.168.0.1:1029
EAP-Message = 0x010700060d20
Message-Authenticator = 0x00000000000000000000000000000000
State = 0x51fda03f50417a07a57694d709af6669
Finished request 2
Going to the next request
--- Walking the entire request list ---
Waking up in 6 seconds...
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
