[RADIATOR] TTLS/EAP setup

Sat Dec 10 08:48:53 UTC 2016

Hello,

> On 09 Dec 2016, at 18:18, rohan.henry cwjamaica.com <rohan.henry at cwjamaica.com> wrote:
> 
> It seems Radiator is not receiving expected response after sending access-challenge to NAS (Telrad station). 
> 
> Does my radiator response look ok?
> 
> ...
> Thu Nov 24 08:25:15 2016: DEBUG: Handling with EAP: code 2, 1, 56, 1
> Thu Nov 24 08:25:15 2016: DEBUG: Response type 1
> Thu Nov 24 08:25:15 2016: DEBUG: EAP result: 3, EAP PEAP Challenge
> Thu Nov 24 08:25:15 2016: DEBUG: AuthBy SQL result: CHALLENGE, EAP PEAP Challenge
> Thu Nov 24 08:25:15 2016: DEBUG: PostAuthHook:  Cypress = Access-Request
> Thu Nov 24 08:25:15 2016: DEBUG: PostAuthHook:  Cypress Reason = EAP PEAP Challenge
> Thu Nov 24 08:25:15 2016: DEBUG: Access challenged for {am=1}c63a2a38c45914908f0394f53834f790 at anuwimax.com: EAP PEAP Challenge
> Thu Nov 24 08:25:15 2016: DEBUG: Packet dump:
> *** Sending to 172.20.152.237 port 33511 ....
> Packet length = 46
> 0b 09 00 2e 33 59 ad 2e a9 25 18 08 e4 12 54 be
> 8b bb 26 6f 4f 08 01 02 00 06 19 20 50 12 b0 bf
> 51 31 b6 fd 7a bd f9 1b 07 b2 6c 23 12 2f
> Code:       Access-Challenge
> Identifier: 9
> Authentic:  3Y<173>.<169>%<24><8><228><18>T<190><139><187>&o
> Attributes:
>         EAP-Message = <1><2><0><6><25>
>         Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
> 

above, Radiator sends a response to EAP-Identity from the client and suggests 
EAP-PEAP (25) to be used.

> Thu Nov 24 08:25:20 2016: DEBUG: Packet dump:
> *** Received from 172.20.152.237 port 33511 ....
> Packet length = 251
> 01 09 00 fb 33 9d a7 be 03 68 98 13 00 4b b5 b3
> 6f b2 6b 2e 01 35 7b 61 6d 3d 31 7d 63 36 33 61
> 32 61 33 38 63 34 35 39 31 34 39 30 38 66 30 33
> 39 34 66 35 33 38 33 34 66 37 39 30 40 61 6e 75
> 77 69 6d 61 78 2e 63 6f 6d 4f 3a 02 01 00 38 01
> 7b 61 6d 3d 31 7d 63 36 33 61 32 61 33 38 63 34
> 35 39 31 34 39 30 38 66 30 33 39 34 66 35 33 38
> 33 34 66 37 39 30 40 61 6e 75 77 69 6d 61 78 2e
> 63 6f 6d 50 12 a2 6c ed 33 5b 7c 92 98 50 86 d4
> 28 5e 81 9f 56 20 05 30 31 38 04 06 0a 01 64 64
> 1f 13 30 30 2d 31 30 2d 45 37 2d 45 32 2d 43 30
> 2d 35 34 1a 0f 00 00 60 b5 2e 09 00 01 01 01 16
> 16 02 3d 06 00 00 00 1b 0c 06 00 00 07 d0 06 06
> 00 00 00 02 1a 0d 00 00 60 b5 03 07 00 00 00 00
> 00 1a 1a 00 00 60 b5 01 14 00 01 05 31 2e 30 02
> 03 01 03 03 01 07 06 00 00 02 8a
> Code:       Access-Request
> Identifier: 9
> Authentic:  3<157><167><190><3>h<152><19><0>K<181><179>o<178>k.
> Attributes:
>         User-Name = "{am=1}c63a2a38c45914908f0394f53834f790 at anuwimax.com"
>         EAP-Message = <2><1><0>8<1>{am=1}c63a2a38c45914908f0394f53834f790 at anuwimax.com
>         Message-Authenticator = <162>l<237>3[|<146><152>P<134><212>(^<129><159>V
>         NAS-Identifier = "018"
>         NAS-IP-Address = 10.1.100.100
>         Calling-Station-Id = "00-10-E7-E2-C0-54"
>         WiMAX-BS-ID = <1><1><1><22><22><2>
>         NAS-Port-Type = Wireless-IEEE-802.16
>         Framed-MTU = 2000
>         Service-Type = Framed-User
>         WiMAX-GMT-Timezone-Offset = 0
>         WiMAX-Capability = Release=1.0,Accounting-Capabilities=IP-Session-Based,Hotlining-Capabilities=Hotline-Profile-Id,ASN-Network-Service-Capabilities=650
> Thu Nov 24 08:25:20 2016: INFO: Duplicate request id 9 received from 172.20.152.237(33511): retransmit reply
> 

The client sends the original request again which is correctly marked as a duplicate.

> Thu Nov 24 08:25:20 2016: DEBUG: Packet dump:
> *** Sending to 172.20.152.237 port 33511 ....
> Packet length = 46
> 0b 09 00 2e 33 59 ad 2e a9 25 18 08 e4 12 54 be
> 8b bb 26 6f 4f 08 01 02 00 06 19 20 50 12 b0 bf
> 51 31 b6 fd 7a bd f9 1b 07 b2 6c 23 12 2f
> Code:       Access-Challenge
> Identifier: 9
> Authentic:  3Y<173>.<169>%<24><8><228><18>T<190><139><187>&o
> Attributes:
>         EAP-Message = <1><2><0><6><25>
>         Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
> 

and the same response is sent again from a duplicate cache.

The reason why the client resends the request is that either the original response 
was lost/dropped in the network or in the air interface (wimax) (this is the more probable cause) 
or the client for some reason rejected the response. If an EAP client does not support the EAP method 
which the server suggests, the client should reply with an EAP NaK and suggests another 
EAP method to be used.

(ref: https://tools.ietf.org/html/rfc3748#section-5.3)

BR
-- 
Tuure Vartiainen <vartiait 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.