[RADIATOR] Eaptype=PEAP choosen even if request is EAP-TLS

[Vandenbroucke Luc]

Heikki,

Thanks 
I tested 1 and 2 and they seem to work. (EAP-Message = /^.{4}\xd/ )

Option 3 and 4 will give me all I need.
But I will follow you advice, and try to use information in the username.

Regards,
Luc Vandenbroucke

-----Original Message-----
From: Heikki Vatiainen [mailto:hvn at open.com.au] 
Sent: dinsdag 28 juni 2011 10:18
To: Vandenbroucke Luc
Cc: 'radiator at open.com.au'
Subject: Re: [RADIATOR] Eaptype=PEAP choosen even if request is EAP-TLS

On 06/24/2011 04:52 PM, Vandenbroucke Luc wrote:

Hello Luc,

> Can anyone tell me, if my hander asks "EapType=PEAP", why it is chosen
> for EAP-TLS ?
> 
> I do have a handler for "EapType=TLS", for the same domain. But this
> handler is never not reached.

With EAPType you should use number, such as 25 for PEAP and when you
want to use name, you should use EAPTypeName.

However, now when I took a better look at your configuration and how EAP
type matching works it looks like your configuration needs other changes
too.

The problem with EAPType and EAPTypeName is they are only filled in
*after* a Handler has been selected. So they can not used for initial
Handler selection.

There are a couple of alternatives how to accomplish Handler selection
by EAP type.

1. If there's anything in the request that differentiates between EAP
types, use it. If for example, User-Name has a prefix or suffix that is
different for TLS and PEAP, the correct Handler can be selected based on
User-Name.

2. Match the EAP type in the EAP-Message attribute directly:
# catch EAP-TLS with 0x13 in the 5th octet
<Handler EAP-Message = /^.{4}\x13/
</Handler>

3. A PreHandlerHook in the Client clause can be used to add e.g a
pseudo-attribute to the request. This attribute can then be used to
match the correct Handler.

4. A PreProcessingHook in a Handler together with an AuthBy Handler can
be similarly to (3.) used to redispatch the request.


The problem with EAP is sometimes the EAP type is negotiated between the
peers and/or there might be an identity exchange that does not specify
the type at all.

For these reasons it would be good if the clients could be configured to
use their desired EAP type directly.

Please let us know how the options I listed look like.

Thanks!
Heikki


>  
> 
>  
> 
> Regards
> 
> Luc Vandenbroucke
> 
>  
> 
> p.s. Our other test are all fine now. So we decided to go with Radiator,
> and buy the pro-pack.
> 
>  
> 
>  
> 
> Config
> 
>                 ....
> 
>  
> 
> <Handler EAPType=PEAP,Realm=myrealm>
> 
>                 AuthBy LSAPEAP
> 
> </Handler>
> 
>  
> 
>  
> 
> <Handler EAPType=TLS,Realm=myrealm>
> 
>                 Identifier HPEAPTLS
> 
>  
> 
>                 ...
> 
>  
> 
>  
> 
> Code:       Access-Request
> 
> Identifier: 176
> 
> Authentic:  |ME22<21><129><199>e<140>Q<140><178><152><5><230>
> 
> Attributes:
> 
>         NAS-Port-Id = "AP2/1"
> 
>         Calling-Station-Id = "00-23-14-EB-CB-A8"
> 
>         Called-Station-Id = "00-0B-0E-CF-26-C8:radroam"
> 
>         Service-Type = Framed-User
> 
>         User-Name = "xxxxxxxxxxxx"
> 
>         NAS-Port = 55256
> 
>         EAP-Message = <2><2><0><6><3><13>
> 
>         NAS-Port-Type = Wireless-IEEE-802-11
> 
>         NAS-IP-Address = 10.73.240.100
> 
>         NAS-Identifier = "Trapeze"
> 
>         Message-Authenticator =
> <129><237><217>e<201>p<142><229><168><154>a<163>s=S0
> 
>  
> 
> Fri Jun 24 15:42:39 2011: DEBUG: Handling request with Handler
> 'EAPType=PEAP,Realm=***', Identifier ''
> 
> Fri Jun 24 15:42:39 2011: DEBUG:  Deleting session for
> Install9 at sckcen.be, 10.73.240.100, 55256
> 
> Fri Jun 24 15:42:39 2011: DEBUG: Handling with Radius::AuthLSA: LSAPEAP
> 
> Fri Jun 24 15:42:39 2011: DEBUG: Handling with EAP: code 2, 2, 6, 3
> 
> Fri Jun 24 15:42:39 2011: DEBUG: Response type 3
> 
> Fri Jun 24 15:42:39 2011: DEBUG: EAP Nak desires type 13
> 
> Fri Jun 24 15:42:39 2011: DEBUG: Desired EAP type TLS (13) not permitted
> 
> Fri Jun 24 15:42:39 2011: DEBUG: EAP result: 1, None of the desired EAP
> types (13) are available
> 
> Fri Jun 24 15:42:39 2011: DEBUG: AuthBy LSA result: REJECT, None of the
> desired EAP types (13) are available
> 
> Fri Jun 24 15:42:39 2011: INFO: Access rejected for ****** : None of the
> desired EAP types (13) are available
> 
> Fri Jun 24 15:42:39 2011: DEBUG: Packet dump:
> 
> *** Sending to 10.73.240.100 port 20001 ....
> 
> 
> 
> SCK-CEN Disclaimer: http://www.sckcen.be/en/Legal-aspects/E-mail-disclaimer
> 
> 
> 
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator


-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.