TLS / SSL negotiation fails when behind Cisco IP phone

2012-09-09 Thread Dan Lundström
Hi!

We are using EAP/TLS for wired authentication on our networks, in one of our 
sites the SSL negotiation fails when the client is connected behind a Cisco 
7962 IP phone. We have this same setup working on other sites. 
The phone model varies between the sites, but I cannot find any information 
about incompatibilities for the particular phone model saying it should be the 
phone that is causing the problem.

I figured that the problem was caused by fragmentation but after adjusting the 
fragment_size parameter in eap.conf, according to the comments..;

#  This can never exceed the size of a RADIUS
#  packet (4096 bytes), and is preferably half
#  that, to accomodate other attributes in
#  RADIUS packet.  On most APs the MAX packet
#  length is configured between 1500 - 1600
#  In these cases, fragment size should be
#  1024 or less.

..without any result, i am not sure anymore.

When I connect the client directly to a switch port, without the IP phone 
in-between, everything works perfect.

Here comes the relevant part of RADIUS debug output, first session - Without IP 
phone, directly connected to the switch [ client - switch ];

--
Found Auth-Type = EAP
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP/tls
[eap] processing type tls
[tls] Authenticate
[tls] processing EAP-TLS
[tls] eaptls_verify returned 7
[tls] Done initial handshake
[tls]  TLS 1.0 Handshake [length 0b2e], Certificate
[tls] chain-depth=2,
[tls] error=0
[tls] -- User-Name = host/US-LAPJAMIESON.us..yyy
[tls] -- BUF-Name = Xxxx Root CA
[tls] -- subject = /C=SE/O=Xxxx Communications AB/OU=IT-group/CN=Xxxx Root CA
[tls] -- issuer  = /C=SE/O=Xxxx Communications AB/OU=IT-group/CN=Xxxx Root CA
[tls] -- verify return:1
[tls] chain-depth=1,
[tls] error=0
[tls] -- User-Name = host/US-LAPJAMIESON.us..yyy
[tls] -- BUF-Name = Xxxx Sub CA
[tls] -- subject = /DC=com/DC=/CN=Xxxx Sub CA
[tls] -- issuer  = /C=SE/O=Xxxx Communications AB/OU=IT-group/CN=Xxxx Root CA
[tls] -- verify return:1
[tls] chain-depth=0,
[tls] error=0
[tls] -- User-Name = host/US-LAPJAMIESON.us..yyy
[tls] -- BUF-Name = US-LAPJAMIESON.us..yyy
[tls] -- subject = /CN=US-LAPJAMIESON.us..yyy
[tls] -- issuer  = /DC=com/DC=/CN=Xxxx Sub CA
[tls] -- verify return:1
[tls] TLS_accept: SSLv3 read client certificate A
[tls]  TLS 1.0 Handshake [length 0086], ClientKeyExchange
[tls] TLS_accept: SSLv3 read client key exchange A
[tls]  TLS 1.0 Handshake [length 0106], CertificateVerify
[tls] TLS_accept: SSLv3 read certificate verify A
[tls]  TLS 1.0 ChangeCipherSpec [length 0001]
[tls]  TLS 1.0 Handshake [length 0010], Finished
[tls] TLS_accept: SSLv3 read finished A
[tls]  TLS 1.0 ChangeCipherSpec [length 0001]
[tls] TLS_accept: SSLv3 write change cipher spec A
[tls]  TLS 1.0 Handshake [length 0010], Finished
[tls] TLS_accept: SSLv3 write finished A
[tls] TLS_accept: SSLv3 flush data
[tls] (other): SSL negotiation finished successfully
SSL Connection Established
--
--

Second part - With IP phone in-between [ client - ipphone - switch ];

--
Found Auth-Type = EAP
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP/tls
[eap] processing type tls
[tls] Authenticate
[tls] processing EAP-TLS
[tls] eaptls_verify returned 7
[tls] Done initial handshake
[tls]  TLS 1.0 Handshake [length 0b2e], Certificate
[tls] chain-depth=2,
[tls] error=0
[tls] -- User-Name = host/US-LAPJAMIESON.us..yyy
[tls] -- BUF-Name = Xxxx Root CA
[tls] -- subject = /C=SE/O=Xxxx Communications AB/OU=IT-group/CN=Xxxx Root CA
[tls] -- issuer  = /C=SE/O=Xxxx Communications AB/OU=IT-group/CN=Xxxx Root CA
[tls] -- verify return:1
[tls] chain-depth=1,
[tls] error=0
[tls] -- User-Name = host/US-LAPJAMIESON.us..yyy
[tls] -- BUF-Name = Xxxx Sub CA
[tls] -- subject = /DC=com/DC=/CN=Xxxx Sub CA
[tls] -- issuer  = /C=SE/O=Xxxx Communications AB/OU=IT-group/CN=Xxxx Root CA
[tls] -- verify return:1 -- verify error:num=7:certificate signature failure
[tls]  TLS 1.0 Alert [length 0002], fatal decrypt_error
TLS Alert write:fatal:decrypt error
TLS_accept: error in SSLv3 read client certificate B
rlm_eap: SSL error error:0407006A:rsa
routines:RSA_padding_check_PKCS1_type_1:block type is not 01
SSL: SSL_read failed inside of TLS (-1), TLS session fails.
TLS receive handshake failed during operation
[tls] eaptls_process returned 4

RE: TLS / SSL negotiation fails when behind Cisco IP phone

2012-09-09 Thread Dan Lundström
I have been looking at possible changes to make on the phone and call manager, 
but cannot find anything that would relate to the behavior we have. Is there a 
way to change MTU value on the phones, I can't find it.  

We have the 7945 model on another site as well and there everything works, I 
have tried with a 7942 here as well and it does not work. I am quite sure that 
the problem is related to the internal switch in the phone, but since the EAP 
package gets through to the authenticating switch there should be a way to get 
it to work. I don't have any other phone models here to test with, and I can't 
find any information about hardware/switch differences in the 7962 and the 7954 
phones.

Can anyone tell from the below sessions if the SSL negotiation fails because of 
fragmentation?

I just found this article;

https://supportforums.cisco.com/thread/163050

Seems like it might be a firmware issue, I will upgrade/downgrade and let you 
know the outcome.

/Dan

 -Original Message-
 From: freeradius-users-
 bounces+dan.lundstrom=axis@lists.freeradius.org [mailto:freeradius-
 users-bounces+dan.lundstrom=axis@lists.freeradius.org] On Behalf Of
 Danner, Mearl
 Sent: den 9 september 2012 16:37
 To: FreeRadius users mailing list
 Subject: RE: TLS / SSL negotiation fails when behind Cisco IP phone
 
 There is a switch in the Cisco phone. All my experience is with a 7945.
 
 There are some ethernet settings in the phone settings - under device
 configuration. They can be controlled locally and some are controlled in Cisco
 Call Manager.
 
 Might look there as a start.
 
 -Original Message-
 From: freeradius-users-
 bounces+jmdanner=samford@lists.freeradius.org [mailto:freeradius-
 users-bounces+jmdanner=samford@lists.freeradius.org] On Behalf Of
 Dan Lundström
 Sent: Sunday, September 09, 2012 9:02 AM
 To: freeradius-users@lists.freeradius.org
 Subject: TLS / SSL negotiation fails when behind Cisco IP phone
 
 Hi!
 
 We are using EAP/TLS for wired authentication on our networks, in one of
 our sites the SSL negotiation fails when the client is connected behind a 
 Cisco
 7962 IP phone. We have this same setup working on other sites.
 The phone model varies between the sites, but I cannot find any information
 about incompatibilities for the particular phone model saying it should be the
 phone that is causing the problem.
 
 I figured that the problem was caused by fragmentation but after adjusting
 the fragment_size parameter in eap.conf, according to the comments..;
 
 #  This can never exceed the size of a RADIUS
 #  packet (4096 bytes), and is preferably half
 #  that, to accomodate other attributes in
 #  RADIUS packet.  On most APs the MAX packet
 #  length is configured between 1500 - 1600
 #  In these cases, fragment size should be
 #  1024 or less.
 
 ..without any result, i am not sure anymore.
 
 When I connect the client directly to a switch port, without the IP phone in-
 between, everything works perfect.
 
 Here comes the relevant part of RADIUS debug output, first session -
 Without IP phone, directly connected to the switch [ client - switch ];
 
 --
 Found Auth-Type = EAP
 # Executing group from file /etc/freeradius/sites-enabled/default
 +- entering group authenticate {...}
 [eap] Request found, released from the list [eap] EAP/tls [eap] processing
 type tls [tls] Authenticate [tls] processing EAP-TLS [tls] eaptls_verify 
 returned
 7 [tls] Done initial handshake [tls]  TLS 1.0 Handshake [length 0b2e],
 Certificate [tls] chain-depth=2, [tls] error=0 [tls] -- User-Name = host/US-
 LAPJAMIESON.us..yyy [tls] -- BUF-Name = Xxxx Root CA [tls] --
 subject = /C=SE/O=Xxxx Communications AB/OU=IT-group/CN=Xxxx Root
 CA [tls] -- issuer  = /C=SE/O=Xxxx Communications AB/OU=IT-
 group/CN=Xxxx Root CA [tls] -- verify return:1 [tls] chain-depth=1, [tls]
 error=0 [tls] -- User-Name = host/US-LAPJAMIESON.us..yyy [tls] --
 BUF-Name = Xxxx Sub CA [tls] -- subject = /DC=com/DC=/CN=Xxxx Sub
 CA [tls] -- issuer  = /C=SE/O=Xxxx Communications AB/OU=IT-
 group/CN=Xxxx Root CA [tls] -- verify return:1 [tls] chain-depth=0, [tls]
 error=0 [tls] -- User-Name = host/US-LAPJAMIESON.us..yyy [tls] --
 BUF-Name = US-LAPJAMIESON.us..yyy [tls] -- subject = /CN=US-
 LAPJAMIESON.us..yyy [tls] -- issuer  = /DC=com/DC=/CN=Xxxx Sub
 CA [tls] -- verify return:1
 [tls] TLS_accept: SSLv3 read client certificate A
 [tls]  TLS 1.0 Handshake [length 0086], ClientKeyExchange
 [tls] TLS_accept: SSLv3 read client key exchange A
 [tls]  TLS 1.0 Handshake [length 0106], CertificateVerify
 [tls] TLS_accept: SSLv3 read certificate verify A
 [tls]  TLS 1.0 ChangeCipherSpec [length 0001] [tls]  TLS 1.0 Handshake
 [length 0010], Finished
 [tls

RE: TLS / SSL negotiation fails when behind Cisco IP phone

2012-09-09 Thread Dan Lundström
The problem was firmware, I works as expected with both older and newer 
versions. So basically don't use firmware version 8.5(2).

Also might be good to know that all of the following phones use the same code 
base;

IP Phones - 7906, 7911, 7931, 7941, 7942, 7945, 7961, 7962, 7965, 7970, 7971  
7975

//Dan

 -Original Message-
 From: freeradius-users-
 bounces+dan.lundstrom=axis@lists.freeradius.org [mailto:freeradius-
 users-bounces+dan.lundstrom=axis@lists.freeradius.org] On Behalf Of
 Dan Lundström
 Sent: den 9 september 2012 17:53
 To: FreeRadius users mailing list
 Subject: RE: TLS / SSL negotiation fails when behind Cisco IP phone
 
 I have been looking at possible changes to make on the phone and call
 manager, but cannot find anything that would relate to the behavior we have.
 Is there a way to change MTU value on the phones, I can't find it.
 
 We have the 7945 model on another site as well and there everything works,
 I have tried with a 7942 here as well and it does not work. I am quite sure 
 that
 the problem is related to the internal switch in the phone, but since the EAP
 package gets through to the authenticating switch there should be a way to
 get it to work. I don't have any other phone models here to test with, and I
 can't find any information about hardware/switch differences in the 7962 and
 the 7954 phones.
 
 Can anyone tell from the below sessions if the SSL negotiation fails because
 of fragmentation?
 
 I just found this article;
 
 https://supportforums.cisco.com/thread/163050
 
 Seems like it might be a firmware issue, I will upgrade/downgrade and let
 you know the outcome.
 
 /Dan
 
  -Original Message-
  From: freeradius-users-
  bounces+dan.lundstrom=axis@lists.freeradius.org
  bounces+[mailto:freeradius-
  users-bounces+dan.lundstrom=axis@lists.freeradius.org] On Behalf
  users-bounces+Of
  Danner, Mearl
  Sent: den 9 september 2012 16:37
  To: FreeRadius users mailing list
  Subject: RE: TLS / SSL negotiation fails when behind Cisco IP phone
 
  There is a switch in the Cisco phone. All my experience is with a 7945.
 
  There are some ethernet settings in the phone settings - under device
  configuration. They can be controlled locally and some are controlled
  in Cisco Call Manager.
 
  Might look there as a start.
 
  -Original Message-
  From: freeradius-users-
  bounces+jmdanner=samford@lists.freeradius.org [mailto:freeradius-
  users-bounces+jmdanner=samford@lists.freeradius.org] On Behalf Of
  Dan Lundström
  Sent: Sunday, September 09, 2012 9:02 AM
  To: freeradius-users@lists.freeradius.org
  Subject: TLS / SSL negotiation fails when behind Cisco IP phone
 
  Hi!
 
  We are using EAP/TLS for wired authentication on our networks, in one
  of our sites the SSL negotiation fails when the client is connected
  behind a Cisco
  7962 IP phone. We have this same setup working on other sites.
  The phone model varies between the sites, but I cannot find any
  information about incompatibilities for the particular phone model
  saying it should be the phone that is causing the problem.
 
  I figured that the problem was caused by fragmentation but after
  adjusting the fragment_size parameter in eap.conf, according to the
  comments..;
 
  #  This can never exceed the size of a RADIUS
  #  packet (4096 bytes), and is preferably half
  #  that, to accomodate other attributes in
  #  RADIUS packet.  On most APs the MAX packet
  #  length is configured between 1500 - 1600
  #  In these cases, fragment size should be
  #  1024 or less.
 
  ..without any result, i am not sure anymore.
 
  When I connect the client directly to a switch port, without the IP
  phone in- between, everything works perfect.
 
  Here comes the relevant part of RADIUS debug output, first session -
  Without IP phone, directly connected to the switch [ client - switch
  ];
 
  --
  
  Found Auth-Type = EAP
  # Executing group from file /etc/freeradius/sites-enabled/default
  +- entering group authenticate {...}
  [eap] Request found, released from the list [eap] EAP/tls [eap]
  processing type tls [tls] Authenticate [tls] processing EAP-TLS [tls]
  eaptls_verify returned
  7 [tls] Done initial handshake [tls]  TLS 1.0 Handshake [length
  0b2e], Certificate [tls] chain-depth=2, [tls] error=0 [tls] --
  User-Name = host/US- LAPJAMIESON.us..yyy [tls] -- BUF-Name =
 Xxxx
  Root CA [tls] -- subject = /C=SE/O=Xxxx Communications
  AB/OU=IT-group/CN=Xxxx Root CA [tls] -- issuer  = /C=SE/O=Xxxx
  Communications AB/OU=IT- group/CN=Xxxx Root CA [tls] -- verify
  return:1 [tls] chain-depth=1, [tls]
  error=0 [tls] -- User-Name = host/US-LAPJAMIESON.us..yyy [tls]
  -- BUF-Name = Xxxx Sub CA [tls] -- subject =
 /DC=com/DC=/CN=Xxxx
  Sub