Re: [Emu] Resolution for TEAP Errata 5128

[Alexander Clouter]

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

[Heikki Vatiainen]

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

[Alexander Clouter]

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

[Joseph Salowey]

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

[Emu] Resolution of TEAP Errata 5127

[Joseph Salowey]

According to the discussion in the interim last week and previous
discussions the resolution of errata 5127 should be as below.  Please
review the text change below and indicate if it aligns with discussion and
implementation.  It is intended that it matches the current draft of RFC7170bis
draft  (Commit

).

Thanks,

Joe

Type: Technical
Original Text:

IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
  "\0" | 64)

 where "|" denotes concatenation, EMSK is the EMSK from the inner
 method, "teapbind...@ietf.org" consists the ASCII value for the
 label "teapbind...@ietf.org" (without quotes), "\0" = is a NULL
 octet (0x00 in hex), length is the 2-octet unsigned integer in
 network byte order, and TLS-PRF is the PRF negotiated as part of
 TLS handshake [RFC5246].

Corrected Text:

IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org",
   0x00 || 0x00 || 0x40)

where "||" denotes concatenation and the TLS-PRF is defined in
[RFC5246] as

PRF(secret, label, seed) = P_(secret, label || seed).

The secret is the EMSK from the inner method, the label is
"teapbind...@ietf.org" consisting of the ASCII value for the
label "teapbind...@ietf.org" (without quotes),  the seed
consists of the "\0" null delimiter (0x00) and 2-octet unsigned
integer length in network byte order (0x00 || 0x4) specified
in [RFC5295].
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Resolution of TEAP Errata 5767

[Oleg Pekar]

The proposal is aligned with previously discussed. One small wording I
would change is:

Section 4.2.13 says:
It MUST be included with the Intermediate-Result TLV to perform
cryptographic binding after each successful EAP authentication method in a
sequence of >>>one or more<<< EAP methods, before proceeding with another
inner EAP method.

Just "sequence" sounds like it denotes the case where there should be more
than one EAP authentication method.

On Thu, Oct 22, 2020 at 3:39 AM Jorge Vergara 
wrote:

> I agree with all the proposed resolutions. For context, there was some
> prior discussion of this errata here:
> https://mailarchive.ietf.org/arch/msg/emu/K_XWBMevKNdxdWskK8RkBt1ZpSQ/
>
>
>
> Jorge Vergara
>
>
>
> *From:* Joseph Salowey 
> *Sent:* Wednesday, October 21, 2020 5:13 PM
> *To:* EMU WG ; Jouni Malinen ; Jorge Vergara <
> jover...@microsoft.com>; Oleg Pekar 
> *Subject:* Resolution of TEAP Errata 5767
>
>
>
> Errata 5767: https://www.rfc-editor.org/errata/eid5767
> 
> Status: Verified
>
> Revision:
>
>
>
> Section 3.3.1 says:
>
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  If more than one method is going to be executed in
>the tunnel, then upon method completion, the server MUST send an
>Intermediate-Result TLV indicating the result.
>
> It should say:
>
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  Upon completion of each EAP authentication method in
>the tunnel, the server MUST send an Intermediate-Result TLV
>indicating the result.
>
>
>
> Section 3.3.3 says:
>
>
>
>   The Crypto-Binding TLV and Intermediate-Result TLV MUST be included
>
>   to perform cryptographic binding after each successful EAP method in a
>
>   sequence of one or more EAP methods.
>
>
>
> It should say:
>
>
>
>   The Crypto-Binding TLV and Intermediate-Result TLV MUST be included
>
>   to perform cryptographic binding after each successful EAP
> authentication
>
>   method in a sequence of one or more EAP methods.
>
>
>
> Section 3.8.3 says:
>
>
>Upon successful completion of the EAP method in Phase 2, the peer and
>server exchange a Crypto-Binding TLV to bind the inner method with
>the outer tunnel and ensure that a man-in-the-middle attack has not
>been attempted.
>
>
>
> It should say:
>
>
>
>Upon successful completion of the EAP authentication method in Phase 2,
>
>the peer and server exchange a Crypto-Binding TLV to bind the inner
>
>method with the outer tunnel and ensure that a man-in-the-middle attack
>
>has not been attempted.
>
>
>
> Section 4.2.11 says:
>
>
>
>The Intermediate-Result TLV provides support for acknowledged
>
>intermediate Success and Failure messages between multiple
>
>inner EAP methods within EAP.
>
>
>
> It should say:
>
>
>
>   The Intermediate-Result TLV provides support for acknowledged
>
>   intermediate Success and Failure messages after each inner EAP
>
>   authentication method.
>
>
>
> Section 4.2.13 says:
>
>
>
>  It MUST be included with the Intermediate-Result TLV to perform
>
>  cryptographic binding after each successful EAP method in a
>
>  sequence of EAP methods, before proceeding with another inner
>
>  EAP method.
>
>
>
> It should say:
>
>
>
>  It MUST be included with the Intermediate-Result TLV to perform
>
>  cryptographic binding after each successful EAP authentication
>
>  method in a sequence of EAP methods, before proceeding with
>
>  another inner EAP method.
>
>
>
> Notes:
>
> TEAP description is somewhat vague in discussion about "EAP methods" vs.
> "EAP authentication methods" as it comes to the EAP methods performed in
> Phase 2 within the TLS tunnel. RFC 3748 defines Identity request/response
> as an EAP method. However, this method is not an "authentication method"
> which is a special case of an method where the Type is 4 or greater.
>
> RFC 7170 uses correct terminology in the first paragraph of Section 3.3.1
> when talking about multiple authentication methods not being allowed by RFC
> 3748 in a single EAP conversation. However, many, but not all, of the
> following "[EAP] method" instances are actually referring to "[EAP]
> authentication method". This results in incorrect claims on when the
> Intermediate-Result TLV and Crypto-Binding TLV are used. They are not used
> after an EAP non-authentication method like Identity (e.g., see the example
> in C.3); they are used after each EAP authentication method like EAP-pwd.
>
> Furthermore, the comment about "more than one method is going to be
> executed in the tunnel" 

Re: [Emu] Resolution of TEAP Errata 5767

[Jorge Vergara]

I agree with all the proposed resolutions. For context, there was some prior 
discussion of this errata here: 
https://mailarchive.ietf.org/arch/msg/emu/K_XWBMevKNdxdWskK8RkBt1ZpSQ/

Jorge Vergara

From: Joseph Salowey 
Sent: Wednesday, October 21, 2020 5:13 PM
To: EMU WG ; Jouni Malinen ; Jorge Vergara 
; Oleg Pekar 
Subject: Resolution of TEAP Errata 5767

Errata 5767: 
https://www.rfc-editor.org/errata/eid5767
Status: Verified
Revision:

Section 3.3.1 says:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  If more than one method is going to be executed in
   the tunnel, then upon method completion, the server MUST send an
   Intermediate-Result TLV indicating the result.

It should say:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  Upon completion of each EAP authentication method in
   the tunnel, the server MUST send an Intermediate-Result TLV
   indicating the result.

Section 3.3.3 says:

  The Crypto-Binding TLV and Intermediate-Result TLV MUST be included
  to perform cryptographic binding after each successful EAP method in a
  sequence of one or more EAP methods.

It should say:

  The Crypto-Binding TLV and Intermediate-Result TLV MUST be included
  to perform cryptographic binding after each successful EAP authentication
  method in a sequence of one or more EAP methods.

Section 3.8.3 says:

   Upon successful completion of the EAP method in Phase 2, the peer and
   server exchange a Crypto-Binding TLV to bind the inner method with
   the outer tunnel and ensure that a man-in-the-middle attack has not
   been attempted.

It should say:

   Upon successful completion of the EAP authentication method in Phase 2,
   the peer and server exchange a Crypto-Binding TLV to bind the inner
   method with the outer tunnel and ensure that a man-in-the-middle attack
   has not been attempted.

Section 4.2.11 says:

   The Intermediate-Result TLV provides support for acknowledged
   intermediate Success and Failure messages between multiple
   inner EAP methods within EAP.

It should say:

  The Intermediate-Result TLV provides support for acknowledged
  intermediate Success and Failure messages after each inner EAP
  authentication method.

Section 4.2.13 says:

 It MUST be included with the Intermediate-Result TLV to perform
 cryptographic binding after each successful EAP method in a
 sequence of EAP methods, before proceeding with another inner
 EAP method.

It should say:

 It MUST be included with the Intermediate-Result TLV to perform
 cryptographic binding after each successful EAP authentication
 method in a sequence of EAP methods, before proceeding with
 another inner EAP method.

Notes:

TEAP description is somewhat vague in discussion about "EAP methods" vs. "EAP 
authentication methods" as it comes to the EAP methods performed in Phase 2 
within the TLS tunnel. RFC 3748 defines Identity request/response as an EAP 
method. However, this method is not an "authentication method" which is a 
special case of an method where the Type is 4 or greater.

RFC 7170 uses correct terminology in the first paragraph of Section 3.3.1 when 
talking about multiple authentication methods not being allowed by RFC 3748 in 
a single EAP conversation. However, many, but not all, of the following "[EAP] 
method" instances are actually referring to "[EAP] authentication method". This 
results in incorrect claims on when the Intermediate-Result TLV and 
Crypto-Binding TLV are used. They are not used after an EAP non-authentication 
method like Identity (e.g., see the example in C.3); they are used after each 
EAP authentication method like EAP-pwd.

Furthermore, the comment about "more than one method is going to be executed in 
the tunnel" does not sound accurate. This applies even if only a single EAP 
authentication method is executed in the tunnel (Identity method is not 
required to be executed). The proposed text in this errata entry addresses 
these two issues in Section 3.3.1. The following additional changes would be 
needed to make rest of the specification use the terms more accurately:

3.3.3: "after each successful EAP method" --> "after each successful EAP 
authentication method"
3.8.3: "completion of the EAP method" --> "completion of the EAP authentication 
method"
4.2.11: "between multiple inner EAP methods within EAP" --> "after each inner 
EAP authentication method"
4.2.13: "after each successful EAP method" --> "after each successful EAP 
authentication method"
___
Emu mailing list

[Emu] Resolution of TEAP Errata 5767

[Joseph Salowey]

Errata 5767: https://www.rfc-editor.org/errata/eid5767
Status: Verified
Revision:

Section 3.3.1 says:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  If more than one method is going to be executed in
   the tunnel, then upon method completion, the server MUST send an
   Intermediate-Result TLV indicating the result.

It should say:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  Upon completion of each EAP authentication method in
   the tunnel, the server MUST send an Intermediate-Result TLV
   indicating the result.

Section 3.3.3 says:

  The Crypto-Binding TLV and Intermediate-Result TLV MUST be included
  to perform cryptographic binding after each successful EAP method in a
  sequence of one or more EAP methods.

It should say:

  The Crypto-Binding TLV and Intermediate-Result TLV MUST be included
  to perform cryptographic binding after each successful EAP authentication
  method in a sequence of one or more EAP methods.

Section 3.8.3 says:

   Upon successful completion of the EAP method in Phase 2, the peer and
   server exchange a Crypto-Binding TLV to bind the inner method with
   the outer tunnel and ensure that a man-in-the-middle attack has not
   been attempted.

It should say:

   Upon successful completion of the EAP authentication method in Phase 2,
   the peer and server exchange a Crypto-Binding TLV to bind the inner
   method with the outer tunnel and ensure that a man-in-the-middle attack
   has not been attempted.

Section 4.2.11 says:

   The Intermediate-Result TLV provides support for acknowledged
   intermediate Success and Failure messages between multiple
   inner EAP methods within EAP.

It should say:

  The Intermediate-Result TLV provides support for acknowledged
  intermediate Success and Failure messages after each inner EAP
  authentication method.

Section 4.2.13 says:

 It MUST be included with the Intermediate-Result TLV to perform
 cryptographic binding after each successful EAP method in a
 sequence of EAP methods, before proceeding with another inner
 EAP method.

It should say:

 It MUST be included with the Intermediate-Result TLV to perform
 cryptographic binding after each successful EAP authentication
 method in a sequence of EAP methods, before proceeding with
 another inner EAP method.

Notes:

TEAP description is somewhat vague in discussion about "EAP methods" vs.
"EAP authentication methods" as it comes to the EAP methods performed in
Phase 2 within the TLS tunnel. RFC 3748 defines Identity request/response
as an EAP method. However, this method is not an "authentication method"
which is a special case of an method where the Type is 4 or greater.

RFC 7170 uses correct terminology in the first paragraph of Section 3.3.1
when talking about multiple authentication methods not being allowed by RFC
3748 in a single EAP conversation. However, many, but not all, of the
following "[EAP] method" instances are actually referring to "[EAP]
authentication method". This results in incorrect claims on when the
Intermediate-Result TLV and Crypto-Binding TLV are used. They are not used
after an EAP non-authentication method like Identity (e.g., see the example
in C.3); they are used after each EAP authentication method like EAP-pwd.

Furthermore, the comment about "more than one method is going to be
executed in the tunnel" does not sound accurate. This applies even if only
a single EAP authentication method is executed in the tunnel (Identity
method is not required to be executed). The proposed text in this errata
entry addresses these two issues in Section 3.3.1. The following additional
changes would be needed to make rest of the specification use the terms
more accurately:

3.3.3: "after each successful EAP method" --> "after each successful EAP
authentication method"
3.8.3: "completion of the EAP method" --> "completion of the EAP
authentication method"
4.2.11: "between multiple inner EAP methods within EAP" --> "after each
inner EAP authentication method"
4.2.13: "after each successful EAP method" --> "after each successful EAP
authentication method"
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Resolution of TEAP Errata

[Joseph Salowey]

I'll be posting proposed errata revisions for a short, 1 week, final review
before sending it off to the Area Director (Roman) who has the
responsibility of the final action.  For more information how errata are
handled and the please see [1].

Please take a little time to review the errata resolution to make sure that
they match what was discussed on the list and in meetings.

Thanks,

Joe

[1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu