how to limit the repeating ldap lookups

[Martin Kraus]

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