On Wed, Aug 28, 2013 at 07:48:38AM +0200, Olivier Beytrison wrote:
server inner-tunnel { authorize { eap
# stop processing authorize on eap identity or mschap success/fail if ((EAP-Type == 1) || (EAP-Message[0] =~ /^0x02..00061a..$/)) { noop } else { # rest of config goes here } } }
The hack I'm currently using for EAP-TLS based on rfc 5216 # EAP-Message - byte 0 = 2 for EAP-Response # byte 1 = Identifier # byte 2-3 = EAP-Message Length including header (for EAP-TLS minimum 6 bytes) # byte 4 = EAP-Type, EAP-TLS = 0x0d (13) # byte 5 = FLAGS (L,M,[SR],R,R,R,R,R) # byte 6-9 = TLS message length (optional if Flag L set) # byte 10+ = TLS data # Empty EAP-Messages are used to acknowledge EAP-Request fragments or are the last message # the client sends at the end of TLS handshake signaling the server has been authenticated # # We would like to do ldap lookups only on the last empty EAP-Message -> not really possible # But we can skip first few empty messages based on the Identifier field if the client # starts at 0x01. If not the we'll have to match all the empty EAP-Message ^0x02..00060d00$ # EAP-Response identifier is copied from the EAP-Request, so the starting point is determined # by NAS asking for EAP-Identity. # # usually 0x01 is the EAP-Identity, 0x02 is NACK to our offered PEAP, 0x03 is the client_hello, # 0x04-0x06 are the EAP-Response that ack server side of the handshake so we skip the first 6 # EAP-Response packets from the client. This is a heuristic, might not work if ( (EAP-Type == EAP-TLS) && (EAP-Message !~ /^0x02([1-9a-f].|0[7-9a-f])00060d00$/) ) { default = return } mk