[RADIATOR] EAP-TLS response encoding question

Markus Moeller huaraz at moeller.plus.com
Thu Jan 16 18:53:56 UTC 2020


Thank you for the quick and detailed response.

I only see before 

The client sending:

EAP-Message = <2><16><0><6><13><0>

with the server  Challenge containing part of the server certificate chain 

So I 'll need to figure out where the client logs the error.

Thank you 
Markus

-----Original Message----- 
From: Heikki Vatiainen 
Sent: Thursday, January 16, 2020 6:43 PM 
To: radiator at lists.open.com.au 
Subject: Re: [RADIATOR] EAP-TLS response encoding question 

On 16/01/2020 20.23, Markus Moeller wrote:
> How can I interpret the response EAP-Message = 
> <2><17><0><17><13><128><0><0><0><7><21><3><1><0><2><1><0> ?   I think 
> <2> means it is a Request and <13> means EAP TLS,

That's correct.

Start with EAP RFC: https://tools.ietf.org/html/rfc3748#section-4.1

<2><17><0><17><13> is the fixed EAP header:
2: response from client
17: identifier
0 17: Two octet length: 17 octets
13: is type - EAP TLS


Then continue with EAP-TLS RFC
https://tools.ietf.org/html/rfc5216#section-3.2

<128><0><0><0><7>
128: Flags: length included
0 0 0 7: TLS message length


Then comes TLS data, for example from Wikipedia:
https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_record

<21><3><1><0><2><1><0>
21: tells it's an alert
3 1: is TLS version (1.0) see above on the page
0 2: is length, it's fixed for an alert
1: Level: Warning
0: Description: Close notify

In other words, the client responded with TLS alert "Warning/Close 
notify". Possible reason is that it does not trust Radiator's 
certificate. This may be caused by untrusted CA or other reasons. It 
also depends on the client. As you can see from the page or TLS RFCs, 
there are a number of specific Descriptions the client could use but now 
it's quite terse.

Another likely option is that the authentication has failed earlier and 
what you see is the final handshake acknowledging the failure. Does the 
log show anything more detailed before the final 
Access-Request/Access-Reject.

Thanks,
Heikki

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

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory,
EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.
_______________________________________________
radiator mailing list
radiator at lists.open.com.au
https://lists.open.com.au/mailman/listinfo/radiator


More information about the radiator mailing list