Hi,
I have several questions about TEAP TLS session resume since I am not sure
I succeeded to interpret the relevant sections of RFC 7170 and RFC 5077
correctly.
1) Does it make sense for TEAP server to support both TLS session resume
using server state and TLS session resume using PAC? Should
Hi Eliot,
The correction is definitely true.
Question 1: The RFC says that no need to send Intermediate-Result TLV after
Basic Password Authentication and when client provided certificate for
authentication during tunnel establishment. What if server requires to
conduct Basic Password
the intention of the RFC to be as
> well, and makes sense to me. I don’t think there needs to be a protocol
> update if this clarification sounds good to all parties. I would welcome
> Jouni’s thoughts as the filer of the errata.
>
>
>
> Jorge
>
>
>
> *From:* Emu
Hi Jouni,
You filed Errata ID: 5767, 5844, 5845 regarding sending of
Intermediate-Result TLV. Can we clarify a general scheme of
sending Intermediate-Result TLV and Crypto-Binding TLV in all cases? It is
not exactly clear what is "EAP authentication method" and what is its
different from "EAP
peers
> did not derive either MSK or EMSK, then I believe the RFC addresses this as
> MSKi = 32 octets of 0x00s. So if one side calculated neither MSK nor EMSK,
> and both sides decided to continue the conversion, then both sides would
> use the zero-MSK for that IMSK[j],
&g
Hi Jorge,
For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning to
find the common method of TLS 1.3 support for all three or you just want to
release TLS 1.3 support at the same time for all three?
For TEAP errata 5770:
Technically TEAP RFC suggests the implicit method of
n TLV in the whole flow
Would that work?
Regards
Oleg
On Wed, May 6, 2020 at 4:57 PM Oleg Pekar wrote:
> Hi Eliot,
> Few thoughts:
>
>- If the current client's certificate was requested via TEAP by
>PKCS#10 TLV - then maybe it makes sense for the client to send
&g
Hi Jouni,
I propose the following fix for the issues described in this errata id:
1) In Section "4.2.13. Crypto-Binding TLV" make "EMSK Compound MAC" and
"MSK Compound MAC" fields 32 octets long (currently 20 octets). The MAC
value is truncated at 32 octets if it is longer than 32 octets or
Hi Eliot,
Few thoughts:
- If the current client's certificate was requested via TEAP by PKCS#10
TLV - then maybe it makes sense for the client to send Request-Action
TLV + PKCS#10 TLV again with the same certificate parameters
- If the current client's certificate was not requested
Hi Terry
>In practise:
>
>* FreeRADIUS sends RADIUS Access-Reject / EAP-Message / EAP-Failure.
>* hostapd's RADIUS server sends RADIUS Access-Reject / EAP-Message /
EAP-Failure.
>* A commercial RADIUS server implementation sends nothing.
Cisco Identity Services Engine RADIUS also returns RADIUS
> 2 The EAP Type sent by the other party in the first TEAP message. This
is a single octet encoded as (0x37)
Shouldn't we clarify the motivation for placing the octet with TEAP type
0x37 into the BUFFER? Joe, I remember you explained that it is for
protection against cross protocol attacks if
>
> It Should say:
>
> 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].
> If no inner EAP method has been run the S-IMCK and CMK are generated as
> above from S-IMCK[0].
Joe, for me it
Few comments:
1) It seems that the server MUST send Crypto-Binding TLV after a single EAP
authentication method, after each of EAP authentications methods in a
sequence, after no inner method but not after
Basic-Password-Authentication. Shouldn't we close this gap for the sake of
simplicity and
>It should say:
>
> EAP method messages are carried within EAP-Payload TLVs defined in
> Section 4.2.10. Upon method completion, the server MUST send an
> Intermediate-Result TLV indicating the result.
Jouni explained in errata 5767 that not all EAP methods are EAP
authentication methods,
0 at 12:29 PM Jorge Vergara
wrote:
>
>
> *From:* Joseph Salowey
> *Sent:* Monday, May 25, 2020 9:27 PM
> *To:* Jorge Vergara
> *Cc:* Oleg Pekar ; Jouni Malinen ;
> EMU WG
> *Subject:* Re: [Emu] TEAP - RFC 7170 - Errata ID 5768
>
>
>
>
>
>
>
&g
Joe, nice proposal. Few questions:
1. We have a case of Basic Password Authentication instead of inner method
thus we should also use Crypto-Binding TLV based on Zero-MSK after it
2. As Eliot mentioned, we have a case of no inner method at all - we should
use Crypto-Binding TLV based on Zero-MSK
suggestions for clarifications. I find them all to be language
> clarifications and don’t believe any exchanges need to be altered..
>
>
>
> Oleg, your final proposal seems to be removing the exchange of
> Intermediate-Result TLVs in the Basic Password Authentication case – I am
>
A typo: "Crypto-Binding TLS" ==> "Crypto-Binding TLV"
On Sun, Nov 1, 2020 at 11:42 PM Joseph Salowey wrote:
> The section 5 revision is rewritten to reflect handling of the case where
> no MSK is generated and text on handling the 0 MSK is moved from errata
> 5770. this erratum could use more
ase since almost all
> discussion regarding Intermediate-Result TLV currently is in the context of
> inner EAP authentication. 3.3.2 should have a MUST statement similar to
> 3.3.1. 3.6 should cover success or failure indications of basic password
> auth like it does EAP methods. 4.2.11 shoul
Right!
One comment on wording: it may cause an illusion that the condition "if the
exchange is successful" relates to the whole sentence and not just to
Crypto-Binding
TLV.
On Thu, Nov 12, 2020 at 5:33 AM Joseph Salowey wrote:
>
>
> On Tue, Nov 10, 2020 at 2:17 PM
The Authority-ID TLV is used by the client to identify the TEAP server it
is talking to. If the same client talks to more than one TEAP server - it
can keep PACs or cached data from all of them identified by
the Authority-ID. If we make it optional in TEAP start message but keep
mandatory in
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
j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) =
>> P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])
>>
>>
>>
>> taken out to 60 bytes. The problem is that the TEAP spec references a
>> TLS-PRF in a way that it does not define. I think the errata poi
misinterpret the Microsoft implementation.
On Thu, Oct 22, 2020 at 6:55 PM Joseph Salowey wrote:
>
>
> On Thu, Oct 22, 2020 at 6:59 AM Oleg Pekar
> wrote:
>
>> Hi all,
>> Speaking about both errata 5127 and 5128, I think we need to align all
>> key derivation calls i
llows the same pattern as the errata we are discussion. I am very
> surprised to hear that Cisco’s implementation may be different. Oleg, could
> you please double check? I have just double checked our implementation.
> Since our implementations interop, I assume we must have the same
> i
Thanks Joe, one comment regarding item #16 is inline below.
On Sun, May 16, 2021 at 9:52 PM Joseph Salowey wrote:
> Hi Oleg,
>
> thanks for the review, comments below:
>
> On Sun, May 16, 2021 at 1:55 AM Oleg Pekar
> wrote:
>
>> Hi, few more comment
To section: 2.2. Identity Verification
1)
If server name matching is not used, then peers may end up trusting
servers for EAP authentication that are not intended to be EAP
servers for the network.
-- comment:
What is meant by "EAP server for the network"?
2)
EAP peer implementations
Hi, few more comments on the draft #15
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/15/:
1)
2.1.1. Authentication
The full handshake in EAP-TLS with TLS 1.3 always
provide forward secrecy by exchange of ephemeral "key_share"
extensions in the ClientHello and ServerHello
yments
>including ones where multiple EAP servers are deployed for high
>availability.
>
>
> On Thu, May 20, 2021 at 10:23 PM Joseph Salowey wrote:
>
>>
>>
>> On Wed, May 19, 2021 at 5:58 AM Alan DeKok
>> wrote:
>>
>>> On May 19, 2021,
On Thu, Jul 8, 2021 at 8:31 AM Mohit Sethi M
wrote:
> Hi Oleg, Joe, all,
> On 7/8/21 8:06 AM, Joseph Salowey wrote:
>
>
>
> On Tue, Jul 6, 2021 at 10:08 PM Joseph Salowey wrote:
>
>>
>>
>> On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar
>> wrote:
&
Alan, agree on the MAC randomization problem. Is there any existing
standard or proposal for the network deployments where the Network Access
Control server needs to track the device with randomized MAC moving between
intranet SSIDs?
About usage of physical MAC address - maybe some client systems
I still see unclearness in Section "2.2. Identity Verification", I'm trying
to look from the implementer's perspective.
1) "Since EAP-TLS deployments may use more than one EAP
server, each with a different certificate, EAP peer implementations
SHOULD allow for the configuration of a unique
+Peter
After thinking a bit more about it - for the sake of the client
implementation clarity, would it be better if we provide the strict
algorithm for server identity check or maybe reference RFC 6125.
On Mon, May 17, 2021 at 11:58 PM Oleg Pekar
wrote:
> To section: 2.2. Ident
Here are my two cents:
1) Section: 2.1. Key Derivation
When talking about EAP types "Type = value of the EAP Method type"
suggest providing an example of a Type here so it will be clear what is it
about for the rest of the document (e.g. for PEAP Type is 0x19)
2) Here TLS-Exporter function is
>When this configuration process fails or does not work, there is typically
no way to inform the user or administrator as to what went wrong. Which
makes it essentially impossible to debug configuration and compatibility
issues.
[Oleg] If the configuration process is conducted by a centralized
Hi all,
It looks like RADIUS RFC 2865, Section "5. Attributes" is ambiguous when it
talks about the attribute value size:
First it says: "The Value field is zero or more octets", then it provides 5
possible value data types none of which allows a zero length value.
Section "5.26.
I submitted errata on this https://www.rfc-editor.org/errata/eid6915
On Thu, Mar 31, 2022 at 5:21 PM Alan DeKok
wrote:
> On Mar 31, 2022, at 10:05 AM, Oleg Pekar
> wrote:
> >
> > It looks like RADIUS RFC 2865, Section "5. Attributes" is ambiguous when
> it talks
I would like to provide comments as well. We should also bump the version
of the protocol so as not to harm the existing implementations (yes, they
implemented the spec with filed errata, the spec is sometimes ambiguous but
those implementations are already on the market).
Regards,
Oleg
On Fri,
Dear workgroup,
Please help me to clarify the next question.
RFC 9190 "EAP-TLS 1.3", Section "5.4. Certificate Revocation" says:
"EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
Requests (OCSP stapling) as specified in [RFC6066] and Section 4.4.2.1 of
[RFC8446]"
Wording
Hi all,
Few more comments:
1) Section "3.3.4. Protected Termination and Acknowledged Result
Indication"
Except as noted below, the Crypto-Binding TLV MUST be
exchanged and verified before the final Result TLV exchange,
regardless of whether or not there is an inner EAP method
Hi all,
Few initial comments:
1) Section "3.3.1. EAP Sequences"
It says "Upon completion of each EAP method in the tunnel, the server MUST
send an Intermediate-Result TLV...". We have discussed previously that:
a) EAP RFC 3748 calls EAP types 1..3 also "EAP methods":
6.2. Method Types
The
After implementing EAP-FAST and TEAP, I see a big value in simplifying the
protocol state machine. If we draw a state machine diagram and it can be
placed on a relatively small piece of [virtual] paper and clearly readable
- it is much better for the implementers. Thus I would vote for keeping a
rked mandatory, then it MUST send a NAK TLV in the
>response, and all the other TLVs in the message MUST be ignored.
> It MUST NOT send a NAK
>TLV for a TLV that is not marked mandatory
[Oleg] Oh, this is a good catch
I created basic password authentication protocol state machine diagram and
wou
43 matches
Mail list logo
