how-to block ads
|
jbibe
Premium,MVM
join:2001-02-22
| reply to Jason Cohen
Re: Questions about WPA2 and WPA
The "Key Renewal Timeout" refers to the Group Transient Key, not the Pairwise Transient Key. Based on my limited tests with Linksys consumer grade devices, the Pairwise Transient Key is not changed. Some, but not all, ZyXEL consumer grade access points include two timeout periods, the Group Key Renewal Timeout and the Re-Authentication Timeout. Since you don't see a re-authentication in your logs, your access point does not include a re-authentication timeout control.
FreeRADIUS does not include any timers. The access point controls all of the timeout periods. | |
Jason Cohen
join:2004-11-06
Waltham, MA
1 edit | jbibe,
Thanks for the response. I also am wondering about the DH parameters that are created in the Freeradius setup. The howto I followed on Paranoid Penguin [»www.linuxjournal.com/article/8151] said to use the command "openssl dhparam -check -text -5 512 -out dh" which creates a DH parameter file with a 512 bit prime. You recommended that one use, "openssl gendh >> dh" which also creates a 512 bit prime. Isn't this insecure, as the current recommended minimum for DH/DSS public keys is 1024 bits. 512 bit keys have already been broken, and 768 bit keys are also considered insecure. Incidentally, the default setting in Freeradius is "dh_key_length = 512" so in addition to creating a DH parameter file with a larger prime, you also need to manually set the DH key length in eap.conf.
Also, when I used Etherreal to capture the EAP-TLS authentiation, I saw that the server cipher suite for TLS was set to "TLS_RSA_WITH_RC4_128_MD5". This is the default setting that Freeradius uses when no cipher suite is manually selected. I'm confused because this ciphersuite does not include support for DH, and Freeradius by default uses the "rsa_key_exchange = no" setting. So, if DH isn't being used, and RSA isn't being used, how is the Master Key created? It seems like DH is necessary because if "dh_file = ..." is commented out, freeradius fails to start. What is DH being used for in the TLS exchange, and is a large DH key necessary or beneficial? | |
Jason Cohen
join:2004-11-06
Waltham, MA
| I read the NIST " Guide to IEEE 802.11i: Robust Security Networks" yesterday [»csrc.nist.gov/publications/draft···p800-97]. I have read on various sites as well on this forum that both WPA and WPA2 use unique encryption keys for each frame. However, the NIST document states that "CCM uses a new Temporal Key every session—with every new STA-AP association. Unlike TKIP, the use of AES at the core of CCM obviates the need to have per-packet keys. As a result, the two-phase key mixing functions of TKIP encapsulation are not present in the CCMP encapsulation." Thus, the encryption key used in WPA2 remains the same until you re-authenticate with the RADIUS server which generates a fresh PMK whereas in TKIP "A two-phase cryptographic key-mixing process occurs to produce a new key for every frame that is transmitted. The process takes a session Temporal Key along with the dynamically changing TSC to create a dynamic WEP key."
So, is there any safe limit to the amount of data or the number of packets that is safe to encrypt with the same Temporal Key? I routinely stream TV shows from my MythTV server over the wireless network. The recordings are appx. 7 mbit/sec (as they're MPEG-2). This leads to massive amounts of data being transferred in the same session. So, for example, yesterday after watching two shows, Windows said that I had received 2 million packets, and sent 4 million- in a period of 2 hours. The total amount of data transferred was around 6 GB. Is this safe? I would think that as a single AES encryption key can be used to encrypt HDs with hundreds of GBs of data, this shouldn't be an issue, but I wanted to verify that it is in fact a safe practice. | |
jbibe
Premium,MVM
join:2001-02-22
| reply to Jason Cohen
said by Jason Cohen  :I also am wondering about the DH parameters that are created in the Freeradius setup. The howto I followed on Paranoid Penguin [» www.linuxjournal.com/article/8151] said to use the command "openssl dhparam -check -text -5 512 -out dh" which creates a DH parameter file with a 512 bit prime. You recommended that one use, "openssl gendh >> dh" which also creates a 512 bit prime. I use "openssl dhparam -check -text -5 512 -out dh" for the generation of the DH parameters. OpenSSL has obsoleted "openssl gendh >> dh".
Isn't this insecure, as the current recommended minimum for DH/DSS public keys is 1024 bits. 512 bit keys have already been broken, and 768 bit keys are also considered insecure. Incidentally, the default setting in Freeradius is "dh_key_length = 512" so in addition to creating a DH parameter file with a larger prime, you also need to manually set the DH key length in eap.conf. I don't remember the dh_key_length setting. It may be one of the changes in the recent releases. I should download and review the latest server information.
Also, when I used Etherreal to capture the EAP-TLS authentiation, I saw that the server cipher suite for TLS was set to "TLS_RSA_WITH_RC4_128_MD5". This is the default setting that Freeradius uses when no cipher suite is manually selected. I'm confused because this ciphersuite does not include support for DH, and Freeradius by default uses the "rsa_key_exchange = no" setting. So, if DH isn't being used, and RSA isn't being used, how is the Master Key created? It seems like DH is necessary because if "dh_file = ..." is commented out, freeradius fails to start. What is DH being used for in the TLS exchange, and is a large DH key necessary or beneficial?
I looked at the packet exchange during an authentication about three years. If my memory is correct, the choice is negotiated during the exchange. I don't remember the exact sequence. I seem to remember the same choice was always used.
I don't remember the ability to select the cipher suite in FreeRADIUS. It may be one of the new features. The default cipher suite may be similar to MD5 authentication. MD5 is the default authentication method, even though the FreeRADIUS notes recommends against using MD5.
For my purposes, a large DH key is probably not necessary, but I am only protecting my home network. I never send anything important over the wireless network, and I only use the wireless network to beta test new wireless cards, access points and gateways. If I had more important wireless information to protect, I would probably increase the size of the key. At least, I would experiment with changing the key. | |
jbibe
Premium,MVM
join:2001-02-22
3 edits | reply to Jason Cohen
said by Jason Cohen :So, is there any safe limit to the amount of data or the number of packets that is safe to encrypt with the same Temporal Key? I routinely stream TV shows from my MythTV server over the wireless network. The recordings are appx. 7 mbit/sec (as they're MPEG-2). This leads to massive amounts of data being transferred in the same session. So, for example, yesterday after watching two shows, Windows said that I had received 2 million packets, and sent 4 million- in a period of 2 hours. The total amount of data transferred was around 6 GB. Is this safe? I would think that as a single AES encryption key can be used to encrypt HDs with hundreds of GBs of data, this shouldn't be an issue, but I wanted to verify that it is in fact a safe practice. CCM requires a new key for every session. It also requires a unique nonce value for each frame protected by the key. CCMP uses a unique 48-bit packet number for each frame.
Your downloads are not significant, even if your computer remains connected for extended periods of time. I recommend that you turn your computer off on a regular basis, but leaving it on for one day should not cause any security concerns. | |
Jason Cohen
join:2004-11-06
Waltham, MA
1 edit | reply to jbibe
You have to manually set "dh_key_length" in eap.conf as it's not in the file by default. I only learned of its existence by running FreeRadius in debug mode with the -X flag. It shows every option set by Freeradius, including many default options which aren't shown in the configuration files.
I'm still don't think DH is even being used. The default cipher suite used by the server is TLS_RSA_WITH_RC4_MD5. Openssl provides this information about this ciphersuite: RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5. So RSA is used for key exchange and authenticaiton, and 128 bit RC4 is used for encryption while MD5 is used for integrity.
You also can manually set this setting in eap.conf with the cipher_list setting which is included in the configuration file. Using a setting of 'HIGH' will use RSA for Kx/Auth, 3DES for encryption, and SHA1 for integrity. I also was able to use RC4-SHA which is the same as RC4-MD5 but uses SHA1 for integrity. | |
jbibe
Premium,MVM
join:2001-02-22 | I seem to remember that Windows XP had a cipher list, and that one was always selected during the exchange. I don't remember the details anymore. | |
Jason Cohen
join:2004-11-06
Waltham, MA
| reply to jbibe
I looked at the packet exchange during an authentication about three years. If my memory is correct, the choice is negotiated during the exchange. I don't remember the exact sequence. I seem to remember the same choice was always used.
The client sends its cipher suite which includes 11 choices. The server then sends its supported list which is usually just RC4-MD5. If the server offers more than one choice, the highest one on the client's list is used. RC4-MD5 is the first client choice, and RC4-SHA is the second.
Unfortunately, the Windows wireless supplicant can't do AES. This is what MS says about the matter:
"In addition to the Data Encryption Standard (DES) and Triple-DES (3DES), Windows Server "Longhorn" and Windows Vista support the following additional algorithms for encrypting data:
•
Advanced Encryption Standard (AES) with cipher block chaining (CBC) and a 128-bit key size (AES 128)
•
AES with CBC and a 192-bit key size (AES 192)
•
AES with CBC and a 256-bit key size (AES 256)
These new encryption algorithms cannot be used for a security association with a computer running Windows Server 2003, Windows XP, or Windows 2000. | |
|
