v4: Can't see TLS certificate fields from `send Access-Accept` section anymore

classic Classic list List threaded Threaded
7 messages Options
| Threaded
Open this post in threaded view
|

v4: Can't see TLS certificate fields from `send Access-Accept` section anymore

Nick Bogdanov
I am using EAP-TLS authentication and trying to read the
%{session-state.TLS-Client-Cert-Subject} attribute in order to set the
reply.Tunnel-Private-Group-Id field.  In v3 I could just add this to
my post-auth section:

        if (TLS-Client-Cert-Subject =~ /\/OU=VLAN 1\//) {
                update reply {
                        &Tunnel-Private-Group-Id = "1"
                }
        }

In v4 I can see the cert fields in the `recv Access-Request` section
(after setting `virtual_server = default` in mods-available/eap) but
they are all empty when I try to read them from the `send
Access-Accept` section.  In fact, if I uncomment these sections from
the default config, the fields are all empty too:

# update reply {
# &Reply-Message += "%{session-state.TLS-Cert-Serial}"
# &Reply-Message += "%{session-state.TLS-Cert-Expiration}"
# &Reply-Message += "%{session-state.TLS-Cert-Subject}"
# &Reply-Message += "%{session-state.TLS-Cert-Issuer}"
# &Reply-Message += "%{session-state.TLS-Cert-Common-Name}"
# &Reply-Message += "%{session-state.TLS-Cert-Subject-Alt-Name-Email}"
#
# &Reply-Message += "%{session-state.TLS-Client-Cert-Serial}"
# &Reply-Message += "%{session-state.TLS-Client-Cert-Expiration}"
# &Reply-Message += "%{session-state.TLS-Client-Cert-Subject}"
# &Reply-Message += "%{session-state.TLS-Client-Cert-Issuer}"
# &Reply-Message += "%{session-state.TLS-Client-Cert-Common-Name}"
# &Reply-Message += "%{session-state.TLS-Client-Cert-Subject-Alt-Name-Email}"
# }

The log says:

(15,8)    update reply {
(15,8)      EXPAND %{session-state.TLS-Cert-Serial}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Cert-Expiration}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Cert-Subject}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Cert-Issuer}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Cert-Common-Name}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Cert-Subject-Alt-Name-Email}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Client-Cert-Serial}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Client-Cert-Expiration}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Client-Cert-Subject}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Client-Cert-Issuer}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Client-Cert-Common-Name}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Client-Cert-Subject-Alt-Name-Email}
(15,8)        --> (null)
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)    } # update reply (noop)


I am running git rev 89b77dc09571cb4ac3cd4d639aee6c17bea23182, built
from source.  I saw something in upgrade.adoc about using the `filter`
directive but it wasn't clear to me what that meant.  Am I missing
something simple or is this a bug?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: v4: Can't see TLS certificate fields from `send Access-Accept` section anymore

Alan DeKok-2
On Feb 16, 2021, at 9:22 PM, Nick Bogdanov <[hidden email]> wrote:
>
> I am using EAP-TLS authentication and trying to read the
> %{session-state.TLS-Client-Cert-Subject} attribute in order to set the
> reply.Tunnel-Private-Group-Id field.  In v3 I could just add this to
> my post-auth section:

  To be honest... v4 is under major development.  We do have tests for all kinds of things.  But not everything works the same as in v3, and not everything is finished.  So it's "buyer beware".

>        if (TLS-Client-Cert-Subject =~ /\/OU=VLAN 1\//) {
>                update reply {
>                        &Tunnel-Private-Group-Id = "1"
>                }
>        }
>
> In v4 I can see the cert fields in the `recv Access-Request` section
> (after setting `virtual_server = default` in mods-available/eap) but
> they are all empty when I try to read them from the `send
> Access-Accept` section.  In fact, if I uncomment these sections from
> the default config, the fields are all empty too:

  Look at the debug output.  You should be able to see when these attributes are added (or not).

  For example, I see:

(6.0)    eap.tls - Continuing EAP-TLS
(6.0)    eap.tls - Got final TLS record fragment (1383 bytes)
(6.0)    eap.tls - [eap-tls verify] = complete
(6.0)    eap.tls - Handshake state - Server SSLv3/TLS write server done (26)
(6.0)    eap.tls - <<< recv TLS 1.2, handshake[length 2381], unknown_handshake_type_0x000b
(6.0)    eap.tls - Adding certificate attributes to session-state
(6.0)    eap.tls -   &session-state.TLS-Client-Cert-Serial = "03"
(6.0)    eap.tls -   &session-state.TLS-Client-Cert-Expiration = "Feb  6 1970 11:23:13 UTC"

> I am running git rev 89b77dc09571cb4ac3cd4d639aee6c17bea23182, built
> from source.  I saw something in upgrade.adoc about using the `filter`
> directive but it wasn't clear to me what that meant.

  See:

 doc/antora/modules/reference/pages/unlang/filter.adoc
doc/antora/modules/reference/pages/unlang/update.adoc

  In v4, this is *extensively* documented.

>  Am I missing
> something simple or is this a bug?

  It's not clear.  The full debug output should help.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: v4: Can't see TLS certificate fields from `send Access-Accept` section anymore

Nick Bogdanov
In reply to this post by Nick Bogdanov
>> In v4 I can see the cert fields in the `recv Access-Request` section
>> (after setting `virtual_server = default` in mods-available/eap) but
>> they are all empty when I try to read them from the `send
>> Access-Accept` section.  In fact, if I uncomment these sections from
>> the default config, the fields are all empty too:

>  Look at the debug output.  You should be able to see when these attributes are added (or not).

Hi Alan,

They are getting set under "authenticate eap" and they are being
correctly parsed under "recv Access-Request".  But then when I hit the
"send Access-Accept" step, they all vanish:

(14)  Received Access-Request ID 237 from [redacted] to [redacted]
length 397 via socket radius_udp server * port 1812
(14)    User-Name = "a"
(14)    NAS-IP-Address = [redacted]
(14)    NAS-Identifier = [redacted]
(14)    Called-Station-Id = [redacted]
(14)    NAS-Port-Type = Wireless-802.11
(14)    Service-Type = Framed-User
(14)    Calling-Station-Id = [redacted]
(14)    Connect-Info = "CONNECT 0Mbps 802.11b"
(14)    Acct-Session-Id = [redacted]
(14)    Acct-Multi-Session-Id = [redacted]
(14)    Mobility-Domain-Id = 21689
(14)    WLAN-Pairwise-Cipher.OUI = [redacted]
(14)    WLAN-Pairwise-Cipher.Suite-Type = 4
(14)    WLAN-Group-Cipher.OUI = [redacted]
(14)    WLAN-Group-Cipher.Type = 4
(14)    WLAN-AKM-Suite.OUI = [redacted]
(14)    WLAN-AKM-Suite.Suite-Type = 3
(14)    Framed-MTU = 1400
(14)    EAP-Message = [redacted]
(14)    State = [redacted]
(14)    Message-Authenticator = [redacted]
(14)  Running request
(14,8)  Restored &session-state
(14,8)    &session-state.Session-State-User-Name = "a"
(14,8)  Running 'recv Access-Request' from file
/root/freeradius-server/pfx/etc/raddb/sites-enabled/default
(14,8)  recv Access-Request {
(14,8)    policy filter_username {
(14,8)      if (&State) {
(14,8)        if (&User-Name) {
(14,8)          if (!&session-state.Session-State-User-Name) {
(14,8)            ...
(14,8)          }
(14,8)          if (&User-Name != &session-state.Session-State-User-Name) {
(14,8)            ...
(14,8)          }
(14,8)        } # if (&User-Name) (...)
(14,8)      } # if (&State) (...)
(14,8)    } # policy filter_username (...)
(14,8)    eap - Peer sent EAP Response (code 2) ID 19 length 153
(14,8)    eap - Continuing on-going EAP conversation
(14,8)    eap - Setting &control.Auth-Type = eap
(14,8)    eap (updated)
(14,8)    if ("%{session-state.TLS-Client-Cert-Common-Name}" != '') {
(14,8)      EXPAND %{session-state.TLS-Client-Cert-Common-Name}
(14,8)         -->
(14,8)      ...
(14,8)    }
(14,8)    files - EXPAND %{session-state.TLS-Client-Cert-Common-Name}
(14,8)    files -    -->
(14,8)    files (noop)
(14,8)    expiration (noop)
(14,8)    logintime (noop)
(14,8)    pap (noop)
(14,8)  } # recv Access-Request (updated)
(14,8)  Running 'authenticate eap' from file
/root/freeradius-server/pfx/etc/raddb/sites-enabled/default
(14,8)  authenticate eap {
(14,8)    eap - Continuing EAP session
(14,8)    eap - Peer sent packet with EAP method TLS (13)
(14,8)    eap - Calling submodule eap_tls
(14,8)    eap (noop)
(14,8)    subrequest {
(14,8)      Creating subrequest (14.0)
(14,8)        EAP-Type = TLS
(14,8)        EAP-Identity = "a"
(14.0)    eap.tls - Continuing EAP-TLS
(14.0)    eap.tls - Got final TLS record fragment (147 bytes)
(14.0)    eap.tls - [eap-tls verify] = complete
(14.0)    eap.tls - Handshake state - Server SSLv3/TLS write server done (26)
(14.0)    eap.tls - <<< recv TLS 1.2, handshake[length 2543],
unknown_handshake_type_0x000b
(14.0)    eap.tls - [verify chain] = ok
(14.0)    eap.tls - Adding certificate attributes to session-state
(14.0)    eap.tls -   &session-state.TLS-Cert-Serial = [redacted]
(14.0)    eap.tls -   &session-state.TLS-Cert-Expiration = "Jun 11
1979 21:19:41 UTC"
(14.0)    eap.tls -   &session-state.TLS-Cert-Subject = [redacted]
(14.0)    eap.tls -   &session-state.TLS-Cert-Common-Name = [redacted]
(14.0)    eap.tls -   &session-state.TLS-Cert-Issuer = [redacted]
(14.0)    eap.tls - [verify chain] = ok
(14.0)    eap.tls - Adding certificate attributes to session-state
(14.0)    eap.tls -   &session-state.TLS-Client-Cert-Serial = [redacted]
(14.0)    eap.tls -   &session-state.TLS-Client-Cert-Expiration = [redacted]
(14.0)    eap.tls -   &session-state.TLS-Client-Cert-Subject = [redacted]
(14.0)    eap.tls -   &session-state.TLS-Client-Cert-Common-Name = [redacted]
(14.0)    eap.tls -   &session-state.TLS-Client-Cert-Issuer = [redacted]
(14.0)    eap.tls -
&session-state.TLS-Client-Cert-X509v3-Basic-Constraints = "CA:FALSE"
(14.0)    eap.tls -
&session-state.TLS-Client-Cert-X509v3-Subject-Key-Identifier =
[redacted]
(14.0)    eap.tls -
&session-state.TLS-Client-Cert-X509v3-Authority-Key-Identifier =
[redacted]
(14.0)    eap.tls - [verify client] = ok
(14.0)    eap.tls - Handshake state - Server SSLv3/TLS read client
certificate (27)
(14.0)    eap.tls - <<< recv TLS 1.2, handshake[length 70],
unknown_handshake_type_0x0010
(14.0)    eap.tls - Handshake state - Server SSLv3/TLS read client key
exchange (28)
(14.0)    eap.tls - <<< recv TLS 1.2, handshake[length 264],
unknown_handshake_type_0x000f
(14.0)    eap.tls - Handshake state - Server SSLv3/TLS read
certificate verify (29)
(14.0)    eap.tls - Handshake state - Server SSLv3/TLS read change
cipher spec (31)
(14.0)    eap.tls - <<< recv TLS 1.2, handshake[length 16],
unknown_handshake_type_0x0014
(14.0)    eap.tls - Handshake state - Server SSLv3/TLS read finished (32)
(14.0)    eap.tls - >>> send TLS 1.2, change_cipher_spec[length 1]
(14.0)    eap.tls - Handshake state - Server SSLv3/TLS write change
cipher spec (35)
(14.0)    eap.tls - >>> send TLS 1.2, handshake[length 16],
unknown_handshake_type_0x0014
(14.0)    eap.tls - Handshake state - Server SSLv3/TLS write finished (36)
(14.0)    eap.tls - Handshake state - SSL negotiation finished successfully (1)
(14.0)    eap.tls - Cipher suite: ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2
Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
(14.0)    eap.tls - Adding TLS session information to request
(14.0)    eap.tls -   &session-state.TLS-Session-Cipher-Suite =
"ECDHE-RSA-AES256-GCM-SHA384"
(14.0)    eap.tls -   &session-state.TLS-Session-Version := "TLS 1.2"
(14.0)    eap.tls - Sending complete TLS record (51 bytes)
(14.0)    eap.tls - [eap-tls process] = handled
(14.0)    eap.tls (handled)
(14,8)    } # subrequest (handled)
(14,8)    eap - Sending EAP Request (code 1) ID 20 length 61
(14,8)    eap (handled)
(14,8)  } # authenticate eap (handled)
(14,8)  Running 'send Access-Challenge' from file
/root/freeradius-server/pfx/etc/raddb/sites-enabled/default
(14,8)  send Access-Challenge {
(14,8)    attr_filter.access_challenge - EXPAND %{User-Name}
(14,8)    attr_filter.access_challenge -    --> a
(14,8)    attr_filter.access_challenge - Matched entry DEFAULT at line 12
(14,8)    attr_filter.access_challenge.post-auth (updated)
(14,8)    handled (handled)
(14,8)  } # send Access-Challenge (handled)
(14,8)  Saving &session-state
(14,8)    &session-state.Session-State-User-Name = "a"
(14,8)  Done request
(14,8)  Sending Access-Challenge ID 237 from [redacted] to [redacted]
length 119 via socket radius_udp server * port 1812
(14,8)    State = [redacted]
(14,8)    Message-Authenticator = [redacted]
(14,8)    EAP-Message = [redacted]
(14,8)  Finished request
proto_radius_udp - cleaning up request in 5.000000s
proto_radius_udp - Received Access-Request ID 238 length 250
radius_udp server * port 1812
(15)  Received Access-Request ID 238 from [redacted] to [redacted]
length 250 via socket radius_udp server * port 1812
(15)    User-Name = "a"
(15)    NAS-IP-Address = [redacted]
(15)    NAS-Identifier = [redacted]
(15)    Called-Station-Id = [redacted]
(15)    NAS-Port-Type = Wireless-802.11
(15)    Service-Type = Framed-User
(15)    Calling-Station-Id = [redacted]
(15)    Connect-Info = "CONNECT 0Mbps 802.11b"
(15)    Acct-Session-Id = [redacted]
(15)    Acct-Multi-Session-Id = [redacted]
(15)    Mobility-Domain-Id = 21689
(15)    WLAN-Pairwise-Cipher.OUI = [redacted]
(15)    WLAN-Pairwise-Cipher.Suite-Type = 4
(15)    WLAN-Group-Cipher.OUI = [redacted]
(15)    WLAN-Group-Cipher.Type = 4
(15)    WLAN-AKM-Suite.OUI = [redacted]
(15)    WLAN-AKM-Suite.Suite-Type = 3
(15)    Framed-MTU = 1400
(15)    EAP-Message = [redacted]
(15)    State = [redacted]
(15)    Message-Authenticator = [redacted]
(15)  Running request
(15,8)  Restored &session-state
(15,8)    &session-state.Session-State-User-Name = "a"
(15,8)  Running 'recv Access-Request' from file
/root/freeradius-server/pfx/etc/raddb/sites-enabled/default
(15,8)  recv Access-Request {
(15,8)    policy filter_username {
(15,8)      if (&State) {
(15,8)        if (&User-Name) {
(15,8)          if (!&session-state.Session-State-User-Name) {
(15,8)            ...
(15,8)          }
(15,8)          if (&User-Name != &session-state.Session-State-User-Name) {
(15,8)            ...
(15,8)          }
(15,8)        } # if (&User-Name) (...)
(15,8)      } # if (&State) (...)
(15,8)    } # policy filter_username (...)
(15,8)    eap - Peer sent EAP Response (code 2) ID 20 length 6
(15,8)    eap - Continuing on-going EAP conversation
(15,8)    eap - Setting &control.Auth-Type = eap
(15,8)    eap (updated)
(15,8)    if ("%{session-state.TLS-Client-Cert-Common-Name}" != '') {
(15,8)      EXPAND %{session-state.TLS-Client-Cert-Common-Name}
(15,8)         -->
(15,8)      ...
(15,8)    }
(15,8)    files - EXPAND %{session-state.TLS-Client-Cert-Common-Name}
(15,8)    files -    -->
(15,8)    files (noop)
(15,8)    expiration (noop)
(15,8)    logintime (noop)
(15,8)    pap (noop)
(15,8)  } # recv Access-Request (updated)
(15,8)  Running 'authenticate eap' from file
/root/freeradius-server/pfx/etc/raddb/sites-enabled/default
(15,8)  authenticate eap {
(15,8)    eap - Continuing EAP session
(15,8)    eap - Peer sent packet with EAP method TLS (13)
(15,8)    eap - Calling submodule eap_tls
(15,8)    eap (noop)
(15,8)    subrequest {
(15,8)      Creating subrequest (15.0)
(15,8)        EAP-Type = TLS
(15,8)        EAP-Identity = "a"
(15.0)    eap.tls - Continuing EAP-TLS
(15.0)    eap.tls - Peer ACKed our handshake fragment.  handshake is finished
(15.0)    eap.tls - [eap-tls verify] = established
(15.0)    eap.tls - [eap-tls process] = established
(15.0)    eap.tls - Validating certificate
(15.0)    eap.tls (yield)
(15.0)    recv Access-Request {
(15.0)      policy filter_username {
(15.0)        if (&State) {
(15.0)          ...
(15.0)        }
(15.0)        elsif (&User-Name) {
(15.0)          ...
(15.0)        }
(15.0)      } # policy filter_username (...)
(15.0)      eap - No EAP-Message, not doing EAP
(15.0)      eap (noop)
(15.0)      if ("%{session-state.TLS-Client-Cert-Common-Name}" != '') {
(15.0)        EXPAND %{session-state.TLS-Client-Cert-Common-Name}
(15.0)           --> [redacted]
(15.0)        files - EXPAND %{session-state.TLS-Client-Cert-Common-Name}
(15.0)        files -    --> [redacted]
(15.0)        files - Found match "[redacted]" on line 3 of
/root/freeradius-server/pfx/etc/raddb/mods-config/files/authorize
(15.0)        files (ok)
(15.0)        if (!ok) {
(15.0)          ...
(15.0)        }
(15.0)        update reply {
(15.0)          &Tunnel-Type = VLAN
(15.0)          &Tunnel-Medium-Type = IEEE-802
(15.0)        } # update reply (noop)
(15.0)        if ("%{session-state.TLS-Client-Cert-Subject}" =~ /[redacted]/) {
(15.0)          EXPAND %{session-state.TLS-Client-Cert-Subject}
(15.0)             --> /CN=[redacted]
(15.0)          ...
(15.0)        }
(15.0)        elsif ("%{session-state.TLS-Client-Cert-Subject}" =~
/[redacted]/) {
(15.0)          EXPAND %{session-state.TLS-Client-Cert-Subject}
(15.0)             --> /CN=[redacted]
(15.0)          update reply {
(15.0)            &Tunnel-Private-Group-Id = "7"
(15.0)          } # update reply (noop)
(15.0)          update session-state {
(15.0)            &Tmp-String-9 = "7"
(15.0)          } # update session-state (noop)
(15.0)        } # elsif ("%{session-state.TLS-Client-Cert-Subject}" =~
/[redacted]/) (noop)
(15.0)      } # if ("%{session-state.TLS-Client-Cert-Common-Name}" != '') (ok)
(15.0)      files - EXPAND %{session-state.TLS-Client-Cert-Common-Name}
(15.0)      files -    --> [redacted]
(15.0)      files - Found match "[redacted]" on line 3 of
/root/freeradius-server/pfx/etc/raddb/mods-config/files/authorize
(15.0)      files (ok)
(15.0)      expiration (noop)
(15.0)      logintime (noop)
(15.0)      pap - No User-Password attribute in the request.  Cannot do PAP
(15.0)      pap (noop)
(15.0)    } # recv Access-Request (ok)
(15.0)    No session data available to cache
(15,8)      Adding session keys
(15,8)        &reply.Vendor-Specific.Microsoft.MPPE-Recv-Key = [redacted]
(15,8)        &reply.Vendor-Specific.Microsoft.MPPE-Send-Key = [redacted]
(15,8)        &reply.EAP-MSK = [redacted]
(15,8)        &reply.EAP-EMSK = [redacted]
(15.0)      &reply.EAP-Session-Id = [redacted]
(15,8)    } # subrequest (ok)
(15,8)    eap - Sending EAP Success (code 3) ID 20 length 4
(15,8)    eap - Cleaning up EAP session
(15,8)    eap (ok)
(15,8)  } # authenticate eap (ok)
(15,8)  Running 'send Access-Accept' from file
/root/freeradius-server/pfx/etc/raddb/sites-enabled/default
(15,8)  send Access-Accept {
(15,8)    update {
(15,8)      &reply += &session-state -> "a"
(15,8)    } # update (noop)
(15,8)    eap (noop)
(15,8)    update reply {
(15,8)      EXPAND %{session-state.TLS-Cert-Serial}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Cert-Expiration}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Cert-Subject}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Cert-Issuer}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Cert-Common-Name}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Cert-Subject-Alt-Name-Email}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Client-Cert-Serial}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Client-Cert-Expiration}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Client-Cert-Subject}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Client-Cert-Issuer}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Client-Cert-Common-Name}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Client-Cert-Subject-Alt-Name-Email}
(15,8)        --> (null)
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)      &Reply-Message += ""
(15,8)    } # update reply (noop)
(15,8)    update reply {
(15,8)      EXPAND %{session-state.Tmp-String-9}
(15,8)        --> (null)
(15,8)      EXPAND %{session-state.TLS-Client-Cert-Subject}
(15,8)        --> (null)
(15,8)      &Tunnel-Type = VLAN
(15,8)      &Tunnel-Medium-Type = IEEE-802
(15,8)      &Tunnel-Private-Group-Id = ""
(15,8)      &Tmp-String-9 := ""
(15,8)    } # update reply (noop)
(15,8)    if ("%{reply.Tunnel-Private-Group-Id}" == "") {
(15,8)      EXPAND %{reply.Tunnel-Private-Group-Id}
(15,8)         -->
(15,8)      reject (reject)
(15,8)    } # if ("%{reply.Tunnel-Private-Group-Id}" == "") (reject)
(15,8)  } # send Access-Accept (reject)
(15,8)  WARNING: Failed running 'send Access-Accept', trying 'send
Access-Reject'


Notes:

1) The above log also reflects some unsuccessful experiments I was
doing to try to get the Tunnel-Private-Group-Id to propagate to the
Access-Accept stage, so some of the variable assignments might not
make sense.

2) I don't think session-state.TLS-Cert-Expiration is being parsed correctly.

3) I didn't enable delivery of every freeradius-users message, so if
you could cc: me on replies that would be much appreciated.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: v4: Can't see TLS certificate fields from `send Access-Accept` section anymore

Alan DeKok-2
On Feb 16, 2021, at 10:44 PM, Nick Bogdanov <[hidden email]> wrote:
>
> They are getting set under "authenticate eap" and they are being
> correctly parsed under "recv Access-Request".  But then when I hit the
> "send Access-Accept" step, they all vanish:

  OK.  I'm seeing that here, too.  And the leak checker is complaining that the certificate attributes are being leaked.

  i.e. they're not cached / freed like they're supposed to be.

> 2) I don't think session-state.TLS-Cert-Expiration is being parsed correctly.

  Yeah, that seems off.  I'll take a look.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: v4: Can't see TLS certificate fields from `send Access-Accept` section anymore

Alan DeKok-2
In reply to this post by Nick Bogdanov
On Feb 16, 2021, at 10:44 PM, Nick Bogdanov <[hidden email]> wrote
> They are getting set under "authenticate eap" and they are being
> correctly parsed under "recv Access-Request".  But then when I hit the
> "send Access-Accept" step, they all vanish:

  Looking into this some more:

* I've fixed the cert expiration timestamp issue

* there was a memory leak which is now fixed

* for various reasons the TLS certs are available in the sub request, and will need to be copied manually (sorry) to the parent

* which means you need to enable `virtual_server = check-eap-tls` in mods-enabled/eap, and then put policies in there

  That should work.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: v4: Can't see TLS certificate fields from `send Access-Accept` section anymore

Nick Bogdanov
On Wed, Feb 17, 2021 at 7:56 AM Alan DeKok <[hidden email]> wrote:

>
> On Feb 16, 2021, at 10:44 PM, Nick Bogdanov <[hidden email]> wrote
> > They are getting set under "authenticate eap" and they are being
> > correctly parsed under "recv Access-Request".  But then when I hit the
> > "send Access-Accept" step, they all vanish:
>
>   Looking into this some more:
>
> * I've fixed the cert expiration timestamp issue
>
> * there was a memory leak which is now fixed
>
> * for various reasons the TLS certs are available in the sub request, and will need to be copied manually (sorry) to the parent
>
> * which means you need to enable `virtual_server = check-eap-tls` in mods-enabled/eap, and then put policies in there
>
>   That should work.

Hmm, still no luck enabling check-eap-tls.  If I set `virtual_server =
check-eap-tls` in mods-enabled/eap and then symlink
sites-available/check-eap-tls to sites-enabled/, it aborts on startup:

Parsing security rules to bootstrap UID / GID / chroot / etc.
main {
  prefix = /root/freeradius-server/pfx
  security {
    allow_core_dumps = no
    allow_vulnerable_openssl = no
    openssl_fips_mode = no
  }
  name = radiusd
  local_state_dir = "/root/freeradius-server/pfx/var"
  run_dir = /root/freeradius-server/pfx/var/run/radiusd
}
Parsing main configuration.
main {
...freeradius-server/pfx/etc/raddb/sites-enabled/check-eap-tls[31]:
virtual server check-eap-tls MUST contain a 'namespace' option


If I add `namespace = check-eap-tls` at the top of the server {}
section, radiusd gets to the end of the handshake and then rejects the
request here:

(8)  Running request
(8)  Restored &session-state
(8)    &session-state.Session-State-User-Name = "a"
(8)  Running 'recv Access-Request' from file
/root/freeradius-server/pfx/etc/raddb/sites-enabled/default
(8)  recv Access-Request {
(8)    policy filter_username {
(8)      if (&State) {
(8)        if (&User-Name) {
(8)          if (!&session-state.Session-State-User-Name) {
(8)            ...
(8)          }
(8)          if (&User-Name != &session-state.Session-State-User-Name) {
(8)            ...
(8)          }
(8)        } # if (&User-Name) (...)
(8)      } # if (&State) (...)
(8)    } # policy filter_username (...)
(8)    chap (noop)
(8)    mschap (noop)
(8)    digest (noop)
(8)    eap - Peer sent EAP Response (code 2) ID 249 length 6
(8)    eap - Continuing on-going EAP conversation
(8)    eap - Setting &control.Auth-Type = eap
(8)    eap (updated)
(8)    files - EXPAND %{%{Stripped-User-Name}:-%{User-Name}}
(8)    files -    --> a
(8)    files (noop)
(8)    expiration (noop)
(8)    logintime (noop)
(8)    pap (noop)
(8)  } # recv Access-Request (updated)
(8)  Running 'authenticate eap' from file
/root/freeradius-server/pfx/etc/raddb/sites-enabled/default
(8)  authenticate eap {
(8)    eap - Continuing EAP session
(8)    eap - Peer sent packet with EAP method TLS (13)
(8)    eap - Calling submodule eap_tls
(8)    eap (noop)
(8)    subrequest {
(8)      Creating subrequest (8.0)
(8)        EAP-Type = TLS
(8)        EAP-Identity = "a"
(8.0)    eap.tls - Continuing EAP-TLS
(8.0)    eap.tls - Peer ACKed our handshake fragment.  handshake is finished
(8.0)    eap.tls - [eap-tls verify] = established
(8.0)    eap.tls - [eap-tls process] = established
(8.0)    eap.tls - ERROR: Failed to find pre-compiled unlang for
section server check-eap-tls { ... }
(8.0)    eap.tls (invalid)
(8)    } # subrequest (invalid)
(8)    eap - Sending EAP Failure (code 4) ID 249 length 4
(8)    eap (invalid)
(8)  } # authenticate eap (invalid)
(8)  Failed to authenticate the user
(8)  Running 'send Access-Reject' from file
/root/freeradius-server/pfx/etc/raddb/sites-enabled/default
(8)  send Access-Reject {


I updated to git rev 1a0623b0cff8691551dcb701d22d2896c207e3a1 since I
saw that you pushed a few commits related to namespaces and virtual
servers, then ran `make clean && make && make install`, then started
with a clean configuration.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: v4: Can't see TLS certificate fields from `send Access-Accept` section anymore

Alan DeKok-2
On Feb 17, 2021, at 3:10 PM, Nick Bogdanov <[hidden email]> wrote:
> Hmm, still no luck enabling check-eap-tls.  If I set `virtual_server =
> check-eap-tls` in mods-enabled/eap and then symlink
> sites-available/check-eap-tls to sites-enabled/, it aborts on startup:
> ..
> ...freeradius-server/pfx/etc/raddb/sites-enabled/check-eap-tls[31]:
> virtual server check-eap-tls MUST contain a 'namespace' option

  OK.  :(  I think that example needs to be updated.

>
> If I add `namespace = check-eap-tls` at the top of the server {}

  No, you may need to add `namespace = tls` IIRC.  I'll have to double-check this.

  Some of the code is still in flux unfortunately.

> section, radiusd gets to the end of the handshake and then rejects the
> request here:
> ...
> (8.0)    eap.tls - ERROR: Failed to find pre-compiled unlang for
> section server check-eap-tls { ... }

  Yes, without a correct `namespace`, the rules aren't compiled.

  We're actually cleaning up this code and examples right now.  It might be a bit before we're done.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html