I am running FreeRADIUS v3.0.x. I am trying to enable EAP Session Resumption, but I am running into some problems. In the eap module it says that two files will be written per session. I am never seeing the .vps file in the cache directory, and the .asn1 file will be written sometimes. For this session the file was written: (7) eap_peap: processing EAP-TLS (7) eap_peap: TLS Length 134 (7) eap_peap: Length Included (7) eap_peap: eaptls_verify returned 11 (7) eap_peap: <<< TLS 1.0 Handshake [length 0046], ClientKeyExchange (7) eap_peap: TLS_accept: SSLv3 read client key exchange A (7) eap_peap: <<< TLS 1.0 ChangeCipherSpec [length 0001] (7) eap_peap: <<< TLS 1.0 Handshake [length 0010], Finished (7) eap_peap: TLS_accept: SSLv3 read finished A (7) eap_peap: >>> TLS 1.0 ChangeCipherSpec [length 0001] (7) eap_peap: TLS_accept: SSLv3 write change cipher spec A (7) eap_peap: >>> TLS 1.0 Handshake [length 0010], Finished (7) eap_peap: TLS_accept: SSLv3 write finished A (7) eap_peap: TLS_accept: SSLv3 flush data SSL: adding session f72abc554bb004769d9c8bf121d63a412b519538ece70b34526f42e787bb5b38 to cache SSL: wrote session f72abc554bb004769d9c8bf121d63a412b519538ece70b34526f42e787bb5b38 to /<logdir>/tlscache/f72abc554bb004769d9c8bf121d63a412b519538ece70b34526f42e787bb5b38.asn1 len=147 However this session was not resumed: (18) eap_peap: processing EAP-TLS (18) eap_peap: eaptls_verify returned 7 (18) eap_peap: Done initial handshake (18) eap_peap: eaptls_process returned 7 (18) eap_peap: FR_TLS_OK (18) eap_peap: Session established. Decoding tunneled attributes (18) eap_peap: PEAP state send tlv success (18) eap_peap: Received EAP-TLV response (18) eap_peap: Success (18) eap_peap: WARNING: No information in cached session f72abc554bb004769d9c8bf121d63a412b519538ece70b34526f42e787bb5b38 (18) eap: Freeing handler The files referred to here was not written at all: (26) eap_ttls: Authenticate (26) eap_ttls: processing EAP-TLS (26) eap_ttls: TLS Length 134 (26) eap_ttls: Length Included (26) eap_ttls: eaptls_verify returned 11 (26) eap_ttls: <<< TLS 1.0 Handshake [length 0046], ClientKeyExchange (26) eap_ttls: TLS_accept: SSLv3 read client key exchange A (26) eap_ttls: <<< TLS 1.0 ChangeCipherSpec [length 0001] (26) eap_ttls: <<< TLS 1.0 Handshake [length 0010], Finished (26) eap_ttls: TLS_accept: SSLv3 read finished A (26) eap_ttls: >>> TLS 1.0 ChangeCipherSpec [length 0001] (26) eap_ttls: TLS_accept: SSLv3 write change cipher spec A (26) eap_ttls: >>> TLS 1.0 Handshake [length 0010], Finished (26) eap_ttls: TLS_accept: SSLv3 write finished A (26) eap_ttls: TLS_accept: SSLv3 flush data SSL: adding session 78a6af3ea358b3a251b2815c7b60124e5009fd6b916932d9a554d872e05aa136 to cache SSL: wrote session 78a6af3ea358b3a251b2815c7b60124e5009fd6b916932d9a554d872e05aa136 to /<logdir>/tlscache/78a6af3ea358b3a251b2815c7b60124e5009fd6b916932d9a554d872e05aa136.asn1 len=147 (38) eap_peap: processing EAP-TLS (38) eap_peap: TLS Length 134 (38) eap_peap: Length Included (38) eap_peap: eaptls_verify returned 11 (38) eap_peap: <<< TLS 1.0 Handshake [length 0046], ClientKeyExchange (38) eap_peap: TLS_accept: SSLv3 read client key exchange A (38) eap_peap: <<< TLS 1.0 ChangeCipherSpec [length 0001] (38) eap_peap: <<< TLS 1.0 Handshake [length 0010], Finished (38) eap_peap: TLS_accept: SSLv3 read finished A (38) eap_peap: >>> TLS 1.0 ChangeCipherSpec [length 0001] (38) eap_peap: TLS_accept: SSLv3 write change cipher spec A (38) eap_peap: >>> TLS 1.0 Handshake [length 0010], Finished (38) eap_peap: TLS_accept: SSLv3 write finished A (38) eap_peap: TLS_accept: SSLv3 flush data SSL: adding session d6d13833c06ec03ff683827076a82fe14adecb384a9ef401a467dc2a225a8853 to cache SSL: wrote session d6d13833c06ec03ff683827076a82fe14adecb384a9ef401a467dc2a225a8853 to /<logdir>/tlscache/d6d13833c06ec03ff683827076a82fe14adecb384a9ef401a467dc2a225a8853.asn1 len=147 Why would the files be written sometimes and not other times, and why are there no vps files for these sessions? Thanks, Don
On 10/04/15 15:47, Donald Sherker wrote:
I am running FreeRADIUS v3.0.x. I am trying to enable EAP Session Resumption, but I am running into some problems. In the eap module it says that two files will be written per session. I am never seeing the .vps file in the cache directory, and the .asn1 file will be written sometimes.
Weird. The files are written at different times as the data becomes available at different times. Can you show a full debug for a failing case?
SSL: wrote session f72abc554bb004769d9c8bf121d63a412b519538ece70b34526f42e787bb5b38 to /<logdir>/tlscache/f72abc554bb004769d9c8bf121d63a412b519538ece70b34526f42e787bb5b38.asn1 len=147
Ok.
(18) eap_peap: WARNING: No information in cached session f72abc554bb004769d9c8bf121d63a412b519538ece70b34526f42e787bb5b38
Ok, that implies no value-pairs were read from <sess>.vps. Can you look and see if that file is missing, empty, or just has no data? Are you sure you're returning cacheable VPs? Are you seeing the: Saving session x vps y in the cache ...debug message in the initial session? The .vps file should look something like this: # SSL cached session SOMEHEX Attr = Value, Attr2 = Value2 If your inner tunnel doesn't actually return any cacheable attributes you'll just get the first two lines and there will be nothing to cache; that's
(18) eap: Freeing handler
The files referred to here was not written at all:
I don't understand. Are you saying the .asn1 files mentioned are not written?
Why would the files be written sometimes and not other times, and why are there no vps files for these sessions?
The way the code works is like this: 1. Feed data to OpenSSL 2. OpenSSL calls back into FreeRADIUS to persist the session if it's new, or load it from disk if it's old and not in-memory - these functions write and read the .asn1 files, respectively. 3. Later, FreeRADIUS either runs an inner auth for new sessions and writes the values to the .vps file, or reads them from the .vps file for a resumed session. There are cases where a .asn1 file will exist without a .vps - for example, if the client gets as far as establishing the TLS tunnel but hangs up before the inner auth completes, there will be no matching .vps. I can't remember if I coded for that that use-case :o( A full debug of the initial session followed by the failing session would really help here. Cheers, Phil
participants (2)
-
Donald Sherker -
Phil Mayers