AW: AW: EAP-TLS Failed in handler question

[Phil Mayers]

On 10/12/12 20:00, PENZ Robert wrote:
> @PhilMayers: Did you get the Mail with the full logfile? do you need more?

Ok, your NAS is buggy I'm afraid. In some small percentage of cases, it 
is not handling the wrapping of EAP id values from 255 to 0.

The following sequence of (redacted) packets shows the problem (see line 
~2389268 in your debug for this example, but there are lots of others in 
there):

Access-Request packet from host NAS port 54217, id=183, length=151
         User-Name = "host/blah"
         EAP-Message = 0x02ff...
         NAS-IP-Address = NAS
         Service-Type = Login-User
         Calling-Station-Id = "MAC"
         NAS-Port-Id = "x:y"
         NAS-Port = x00y
         NAS-Port-Type = Ethernet
         Message-Authenticator = 0x26710066ee2e161ba4979519e82cde59
...
[eap] EAP packet type response id 255 length 33
...
+- entering group EAP {...}
[eap] EAP Identity
[eap] processing type tls
[tls] Requiring client certificate
[tls] Initiate
[tls] Start returned 1
...
Sending Access-Challenge of id 183 to 10.15.132.5 port 54217
         EAP-Message = 0x010000060d20
         Message-Authenticator = 0x00000000000000000000000000000000
         State = 0xe043a0c1e043ad9227375e26b2f8cb62

Note that the access-request contains an EAP response with id=255, and 
we return an EAP request with id=0, having wrapped around. The NAS 
follows up with:

Access-Request packet from host 10.15.132.5 port 54217, id=184, length=241
         User-Name = "host/blah"
         EAP-Message = 0x02ff...
         NAS-IP-Address = NAS
         Service-Type = Login-User
         Calling-Station-Id = "MAC"
         NAS-Port-Id = "x:y"
         NAS-Port = x00y
         NAS-Port-Type = Ethernet
         State = 0xe043a0c1e043ad9227375e26b2f8cb62
         Message-Authenticator = 0x03a814fd68371689281f1e66a4728614
...
[eap] EAP packet type response id 255 length 105
...
rlm_eap: No EAP session matching the State variable.

That is - we send an Access-Challenge containing an EAP request id=0, 
the client responds with an Access-Request containing EAP response 
id=255. This is obviously wrong.

FreeRADIUS mixes certain data into the "State" value with a "xor" 
including the EAP id - that's why you're getting that particular error 
message, but the underlying problem is that the NAS is not always 
handling EAP id value wrap correctly.

I'm curious as to why the EAP id values are so large - I don't think 
most NASes do this, they start from id=1 on every conversation, but I 
don't know if it's legal.

The ID wrapping seems to work in other cases; I'm not certain, but it 
*may* be that it only fails if the sequence is:

C: access-request EAP-response id=255 EAP-Identity
S: access-challenge EAP-request id=0 PEAP-start
C: access-request EAP-response id=255 PEAP-data

i.e. if the initial EAP-identity is the one with id=255.

But anyway - I think your NAS is buggy. There's no way you can solve 
this in FreeRADIUS - you obviously can't rewrite the EAP id, so I think 
you'll need to open a bug report with the vendor.

There is one thing you *might* be able to do which *might* work, but 
it's dependent on what the NAS does - if I'm right and it's only 
Identity packets that don't wrap properly, you might be able to detect 
EAP identity packets and modify the ID and *maybe* the Extreme switch 
will reply in-sequence. Like so:

authorize {
   if ("%{EAP-Message[0]}" =~ /^0x02ff(....)01(.+)/) {
     # we have an EAP-identity packet id=255, see if we can force a wrap
     update request {
       EAP-Message := "0x0201%{1}01%{2}"
     }
   }
   ....
}

However - I have no idea if this syntax will even work, and to be honest 
I'm extremely dubious that, if it does, the Extreme would respond properly.

Cheers,
Phil