Hi, This is regarding seed label which is used in PRF(Pseudo random function) to derive session keys. PEAPv0: https://tools.ietf.org/html/draft-kamath-pppext-peapv0-00 - I don't see any mention of label but look like it uses *client EAP encryption ? *Any official draft or RFC mentioned PEAPv0 uses this label ? PEAPv1: https://tools.ietf.org/html/draft-josefsson-pppext-eap-tls-eap-05 *client PEAP encryption* PEAPv2: https://tools.ietf.org/html/draft-josefsson-pppext-eap-tls-eap-10 *client EAP encryption* So on the *client *side the code should be something like if(PEAP_version ==1) label is *client PEAP encryption* otherwise // For version 0 and 2 label is *client PEAP encryption* This look OK? Why PEAPv2 uses old label ?
On Sep 14, 2016, at 2:04 AM, Chitrang Srivastava <chitrang.srivastava@gmail.com> wrote:
This is regarding seed label which is used in PRF(Pseudo random function) to derive session keys.
PEAPv0: https://tools.ietf.org/html/draft-kamath-pppext-peapv0-00 - I don't see any mention of label but look like it uses *client EAP encryption ? *Any official draft or RFC mentioned PEAPv0 uses this label ?
This list is for questions about FreeRADIUS. If you want to learn more about the standards, ask the authors of the standards.
So on the *client *side the code should be something like
If you're writing an EAP client, stop now. Use wpa_supplicant, which works everywhere, and implements everything. Writing another EAP client is a*terrible* idea. It will be vaguely compatible with existing systems, but not completely compatible. And all of the RADIUS server authors will have to spend time with YOUR customers, explaining why your software is broken. Don't write an EAP client. Alan DeKok.
Thanks Alan, Yeah I was also not sure why PEAPv02 start using old seed. Could it be because most PEAPv1 implementation still use old seed and hence new draft thought of falling to old seed? Also is their any draft which mandate old seed for PEAPv0 because the draft didn't say anything about it. A quote from draft says " [a] The PEAPv2 tunnel key (TK) is calculated using the first 40 octets of the (secret) key material generated as described in the EAP-TLS algorithm ([RFC2716] Section 3.5 <https://tools.ietf.org/html/rfc2716#section-3.5>). More explicitly, the TK is the first 40 octets of the PRF as defined in [RFC2716 <https://tools.ietf.org/html/rfc2716>]: PRF(master secret,"client EAP encryption", random) Where random is the concatenation of client_hello.random and server_hello.random ” On 14 Sep 2016 11:34 a.m., "Chitrang Srivastava" < chitrang.srivastava@gmail.com> wrote:
Hi,
This is regarding seed label which is used in PRF(Pseudo random function) to derive session keys.
PEAPv0: https://tools.ietf.org/html/draft-kamath-pppext-peapv0-00 - I don't see any mention of label but look like it uses *client EAP encryption ? *Any official draft or RFC mentioned PEAPv0 uses this label ? PEAPv1: https://tools.ietf.org/html/draft-josefsson-pppext-eap- tls-eap-05 *client PEAP encryption* PEAPv2: https://tools.ietf.org/html/draft-josefsson-pppext-eap- tls-eap-10 *client EAP encryption*
So on the *client *side the code should be something like
if(PEAP_version ==1) label is *client PEAP encryption* otherwise // For version 0 and 2 label is *client PEAP encryption*
This look OK? Why PEAPv2 uses old label ?
On Sep 14, 2016, at 11:02 AM, Chitrang Srivastava <chitrang.srivastava@gmail.com> wrote:
Thanks Alan, Yeah I was also not sure why PEAPv02 start using old seed. Could it be because most PEAPv1 implementation still use old seed and hence new draft thought of falling to old seed?
How about asking the document authors, like I suggested? Or did you not read my message? I don't know, and I don't care. There is similarly no reason for you to know, either. If you need an implementation of EAP, use wpa_supplicant. If you are just interesting in reading the specs, go ask the document authors. I didn't write the specs, and I know nothing about them. I hope that's clear. Alan DeKok.
participants (2)
-
Alan DeKok -
Chitrang Srivastava