Re: [Emu] Resolution for TEAP Errata 5128
On Mon, 9 Jan 2023, at 14:11, Heikki Vatiainen wrote: >> On a related note, whilst we are here, it does raise the question on how we >> got: >> >> "...the length is 64 octets..." and "First 32 octets of TLS-PRF(...)" >> >> The '0x00 || 0x40' (64 network order 16bit length concatenation) looks >> superfluous and I cannot see what they add here (as the label is not >> recycled elsewhere) and makes me wonder if it was unintended? > > See https://www.rfc-editor.org/rfc/rfc5295#section-3.1 > Because IMSK is derived from EMSK I think it has to be defined as currently > shown in draft 7170bis-02. One of RFC 5295 requirements is that the derived > key, in this case IMSK, has to be at least 64 octets. > > Maybe this clarifies section 5.2 in the draft (be specific that 64 octets are > needed by using [0..63] notation): >IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org", 0x00 || > 0x00 || 0x40) [0..63] This makes perfect sense, thanks for pulling up the 'why' for me. > This means that two iterations of TLSv1.2 P_hash(secret, seed) are needed > with. > o secret=EMSK; and > o seed = "teapbind...@ietf.org", 0x00 || 0x00 || 0x40 > > One iteration would give enough data, but RFC 5295 requires to pull 64 > octets. I haven't implemented TEAP yet, but the above is how I'd do to get > IMSK. For fools like me who don't think to follow "as defined in RFC5295" (thinking he has to read the whole darn thing, pffft), lets update the reference to include the section reference too: "...`then the IMSK SHOULD be derived from the EMSK as defined in RFC5295, section 3.1."` `Cheers` ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Resolution for TEAP Errata 5128
On Mon, 9 Jan 2023 at 10:57, Alexander Clouter wrote: Problem is this section has the instruction "generate 64 bytes, use the > first 32..." and after personally getting tripped up[1] on the different > though used with TLS-Exporter which for TLSv1.3 now generates wildly > different outputs depending on the length you request. > > So do we think implementers treat the PRF function as a '(stable) stream > output function' or a 'hashing function'? It works as the former but when > you use it it feels like the latter. > My suggestion: see how the PRF is defined and use it accordingly. For example, with TLSv1.2 default PRF one needs to call P_hash as many times as needed to get at least the number of octets that are required before truncation. Then truncate if needed. As seen below (IMSK definition for TEAP), the length of defined output affects P_hash output therefore it's important to know how much output is needed and what the possible truncation is. Truncation must define clearly what is removed and what is left. For example 'First 32 octets' tells what is used after truncation. I think the TLSv1.2 PRF definition provides the definition and example that is clear enough: https://www.rfc-editor.org/rfc/rfc5246#section-5 > So two options: > > 1. I do like the amendment to use the language "First N octets of > TLS-PRF(..." but it would be helpful to include with it a statement along > the lines that PRF/P_ outputs a stable infinite *stream* of > pseudorandom wonder. > > 2. We update the PRF/P_ function definition updated to include > 'length' (as actual implementations *do* take in a length to know how much > stuff to generate) just so we push it under the noses of implementers and > ready them for the excitement and pitfalls of TLSv1.3. > I'd say it would be enough to tell that successful using PRF requires taking a look at the definition. Such as Section 5 in the TLSv1.2 RFC. With TLS exporter things are easier because length is one of the inputs. > So whilst I prefer the amendment language, I think for communication and > clarity reasons adding 'length' to the PRF/P_ is the better options > as it makes it literally closer to how those functions are in practice > implemented and called; plus TLS-Exporter is now sensitive to length to we > gain some kind of symmetry there too. > > On a related note, whilst we are here, it does raise the question on how > we got: > > "...the length is 64 octets..." and "First 32 octets of TLS-PRF(...)" > > The '0x00 || 0x40' (64 network order 16bit length concatenation) looks > superfluous and I cannot see what they add here (as the label is not > recycled elsewhere) and makes me wonder if it was unintended? > See https://www.rfc-editor.org/rfc/rfc5295#section-3.1 Because IMSK is derived from EMSK I think it has to be defined as currently shown in draft 7170bis-02. One of RFC 5295 requirements is that the derived key, in this case IMSK, has to be at least 64 octets. Maybe this clarifies section 5.2 in the draft (be specific that 64 octets are needed by using [0..63] notation): IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org", 0x00 || 0x00 || 0x40) [0..63] This means that two iterations of TLSv1.2 P_hash(secret, seed) are needed with. o secret=EMSK; and o seed = "teapbind...@ietf.org", 0x00 || 0x00 || 0x40 One iteration would give enough data, but RFC 5295 requires to pull 64 octets. I haven't implemented TEAP yet, but the above is how I'd do to get IMSK. Part of my reasoning is later in the same section we see TLS-PRF(...) with > what is obviously a length field: > > IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" || IMSK[j], > 60) > S-IMCK[j] = first 40 octets of IMCK[j] > CMK[j] = last 20 octets of IMCK[j] > > This makes me believe that originally we were meant to see: > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" || 0x00, > 64) > > This aligns nicely with the 'label | seed' definition seen earlier for > PRF/P_ too. > Not to sure why the '0x00' is still needed, but maybe it was to stop > people messing up the seed with a NULL/empty value rather than a single NUL > byte or vice versa; this way it is explicitly described/read-as "seed is > 0x00" and clear to the implementer. > > Anyway, pondering on history here is mostly irrelevant as Windows, Cisco > ISE, hostapd and now FreeRADIUS all have implemented '... || 0x00 || 0x00 > || 0x40'. > As mentioned above, I think this comes from RFC 5295. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Resolution for TEAP Errata 5128
On Mon, 9 Jan 2023, at 03:34, Joseph Salowey wrote: > The definition of the TLS-PRF is given in 5246 as: > > PRF(secret, label, seed) = P_(secret, label | seed) > > This construction only defines 3 parameters and does not define a length. I > don't think current implementations include the length as an input to the key > derivation so I think the following is the correct resolution: >From a literal statement, you do need a length, as PRF outputs an output >stream, so implementations knows how much stuff to emit and do not use >infinity RAM. https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/src/modules/rlm_eap/libeap/mppe_keys.c#L157-L165 https://w1.fi/cgit/hostap/tree/src/crypto/sha256-tlsprf.c Do you mean "length is irrelevant as an input" as it has no impact on the content of the output stream? > Original Text (Section 5.2): > [snipped] > > Corrected Text (Section 5.2): > [snipped] > > In addition there are similar corrections to section 5.3 > > Original Text: > [snipped] > > New Text (Section 5.3): > [snipped] Problem is this section has the instruction "generate 64 bytes, use the first 32..." and after personally getting tripped up[1] on the different though used with TLS-Exporter which for TLSv1.3 now generates wildly different outputs depending on the length you request. So do we think implementers treat the PRF function as a '(stable) stream output function' or a 'hashing function'? It works as the former but when you use it it feels like the latter. So two options: 1. I do like the amendment to use the language "First N octets of TLS-PRF(..." but it would be helpful to include with it a statement along the lines that PRF/P_ outputs a stable infinite *stream* of pseudorandom wonder. 2. We update the PRF/P_ function definition updated to include 'length' (as actual implementations *do* take in a length to know how much stuff to generate) just so we push it under the noses of implementers and ready them for the excitement and pitfalls of TLSv1.3. So whilst I prefer the amendment language, I think for communication and clarity reasons adding 'length' to the PRF/P_ is the better options as it makes it literally closer to how those functions are in practice implemented and called; plus TLS-Exporter is now sensitive to length to we gain some kind of symmetry there too. On a related note, whilst we are here, it does raise the question on how we got: "...the length is 64 octets..." and "First 32 octets of TLS-PRF(...)" The '0x00 || 0x40' (64 network order 16bit length concatenation) looks superfluous and I cannot see what they add here (as the label is not recycled elsewhere) and makes me wonder if it was unintended? Part of my reasoning is later in the same section we see TLS-PRF(...) with what is obviously a length field: IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" || IMSK[j], 60) S-IMCK[j] = first 40 octets of IMCK[j] CMK[j] = last 20 octets of IMCK[j] This makes me believe that originally we were meant to see: IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" || 0x00, 64) This aligns nicely with the 'label | seed' definition seen earlier for PRF/P_ too. Not to sure why the '0x00' is still needed, but maybe it was to stop people messing up the seed with a NULL/empty value rather than a single NUL byte or vice versa; this way it is explicitly described/read-as "seed is 0x00" and clear to the implementer. Anyway, pondering on history here is mostly irrelevant as Windows, Cisco ISE, hostapd and now FreeRADIUS all have implemented '... || 0x00 || 0x00 || 0x40'. Cheers [1] I had Alan add a paragraph on this to https://datatracker.ietf.org/doc/html/draft-ietf-emu-tls-eap-types-09#section-2.1 as I lost a day or so wondering why my EAP-whatever/TLSv1.3 was not working ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Resolution for TEAP Errata 5128
I think we still have an open issue with 5128. The following resolutions differ from what is currently in RFC7170bis. Please review the text changes below and indicate if it aligns with implementation and discussion. Thanks, Joe The definition of the TLS-PRF is given in 5246 as: PRF(secret, label, seed) = P_(secret, label | seed) This construction only defines 3 parameters and does not define a length. I don't think current implementations include the length as an input to the key derivation so I think the following is the correct resolution: Original Text (Section 5.2): The derivation of S-IMCK is as follows: S-IMCK[0] = session_key_seed For j = 1 to n-1 do IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60) S-IMCK[j] = first 40 octets of IMCK[j] CMK[j] = last 20 octets of IMCK[j] where TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246]. Corrected Text (Section 5.2): The derivation of S-IMCK is as follows: S-IMCK[0] = session_key_seed For j = 1 to n-1 do IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) S-IMCK[j] = first 40 octets of IMCK[j] CMK[j] = last 20 octets of IMCK[j] The TLS-PRF is defined in [RFC5246] as PRF(secret, label, seed) = P_(secret, label | seed), where "|" denotes concatenation. The secret is S-IMCK[j-1], the label is ASCII value for the text "Inner Methods Compound Keys" without quotes, and the seed consists of IMSK[j]. In addition there are similar corrections to section 5.3 Original Text: MSK and EMSK are generated as part of the IMCKn key hierarchy as follows: MSK = TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64) EMSK = TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function", 64) where j is the number of the last successfully executed inner EAP method. New Text (Section 5.3): MSK = the first 64 octets of TLS-PRF(S-IMCK[j], "Session Key Generating Function") EMSK = the first 64 octets of TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function") The TLS-PRF is defined in [RFC5246] as PRF(secret, label, seed) = P_(secret, label | seed), where "|" denotes concatenation. The secret is S-IMCK[j] where j is the number of the last generated S-IMCK from section 5.2. The label is is the ASCII value for the string without quotes. The seed is empty (0 length) and omitted from the derivation. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
