is to have a
> requirements discussion in terms of the sorts of operations we would like to
> see as part of the authentication process – as opposed to elsewhere.
>
> I see tremendous opportunity here, to be honest. But it's a lot of work.
I agree.
Alan DeKok.
ere, even at the EAP level. But They don't
> all fit together well.
I have a document I'll publish shortly.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
to allow
> seamless transition.
Yes, that makes sense. Perhaps instead:
SHOULD allow for the configuration of one or more trusted root (CA
certificates)
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Jul 8, 2021, at 12:42 PM, Joseph Salowey wrote:
>
> I created PR that I think captures these suggestions and another editorial
> fix - https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/87
I think it looks good.
Alan DeKok.
__
dback / comments are welcome.
> Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-dekok-emu-eap-usability-00.txt
> Date: July 12, 2021 at 1:55:58 PM EDT
> To: "Alan DeKok"
>
>
> A new version of I-D, dra
there's some network connection available, everything else can be
automatic.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
the normative text earlier, then people would ask "why
these decisions?", only to have them answered later in the document.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ning network, it
can be easier to write a simpler utility which downloads information. Among
other benefits, there is also a clear separation of roles between network
access, and configuration changes.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
I propose to add a new section which discusses identities.
As background, an (un-named) vendor recently made changes to their EAP stack.
The configuration for TTLS/PEAP now takes the external (anonymous) identity,
and uses that as the inner identity.
i.e. instead of sending "@example.com
:
* it leverages web PKI to bootstrap TLS-based EAP methods
* it does provisioning over standard internet protocols, instead of extending
the supplicant.
I think both of the above are useful. Using EAP as a generic transport layer
for provisioning seems like a poor choice.
Alan DeKok.
___
On Jul 27, 2021, at 1:50 PM, Alan DeKok wrote:
>> We are trying to avoid wheel reinvention. The novel bit here is the mutual
>> authentication in the TLS stack based on the already defined Wi-Fi Alliance
>> DPP bootstrap key.
The novel bit in the EAP-DPP draft, yes.
My l
rovisioning. It could (with no loss of generality) use another method,
such as client certificates.
> I don't think you're trying to solve the same problem we are.
Pretty much. I suspect there may be some overlap, and I'd like to see if
there'
ned and
> using
> TLS to authenticate it using tools which were defined to authenticate TLS.
> We're just
> proposing to use those tools in a new way.
Yup.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
r realm cannot be
"usern...@example.org".
> On Jul 26, 2021, at 7:45 AM, Alan DeKok wrote:
>
> I propose to add a new section which discusses identities.
>
> As background, an (un-named) vendor recently made changes to their EAP
> stack. The configuration for
ntity is for routing, and the inner identity is controlled and
provisioned by the provider.
So I can't think of many good reasons to have different outer/inner realms.
The use-cases are small, and rare.
I'm OK with not forbidding it. But I think there needs to be strong
n it would be good to
explain when that's used, and why.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
27;t anyone discuss it
before this conversation. If it's widely used, then the draft should allow it.
If it's rare to non-existent, then IMHO the draft should suggest it's not a
good idea.
Alan DeKok.
___
Emu mailing list
Emu@iet
On Aug 3, 2021, at 11:36 AM, Tim Cappalli wrote:
> It is becoming even more common with Passpoint becoming the preferred
> deployment model.
OK. I'll update the draft.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.
IUS Access-Request.
>
> So my question is, besides EAP-TTLS, is there an EAP protocol that is widely
> supported and can be used for piggybacking a customized protocol?
> Thanks,.
TTLS seems like the best approach. Inside of that you can use EAP-Message,
and a vendor-sp
e to have updates within a few weeks,
> I agree with Alan that it would be good if it is published quite soon after
> EAP-TLS 1.3. It is important to begin transitioning all the TLS based EAP
> methods to TLS 1.3.
I agree.
Alan DeKok.
__
On Jan 15, 2022, at 5:53 AM, John Mattsson
wrote:
>
> On Oct 18, 2021, Alan DeKok wrote:
>
> >Implementors are doing final interoperability testing on client && server
> >implementations. We hope to have updates within a few weeks,
>
> Any updates on thi
the users identity must be public, which compromises privacy.
I'm not sure how this is preferable to TTLS + PAP.
>draft-ingles-eap-edhoc
That seems useful for limited situations (i.e. IoT). It also has issues with
publicizing identities.
>draft-chen-emu
ful for limited situations (i.e. IoT). It also has issues
> with publicizing identities.
>
> John: I think the only thing that is missing is to mandate use of ananymous
> NAIs.
I don't see any provision in the draft for providing a "real" identity. So
the only NAI used is the outer one, which therefore cannot be fully anonymized.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
dra...@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the EAP Method Update WG of the IETF.
>
>Title : TLS-based EAP types and TLS 1.3
> Author : Alan DeKok
>
roup interested in meeting on?
There's not a lot left which is critical, I think.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
configuration format in the IETF many
years ago. It never got traction, so he went to the WiFi alliance. Their
latest spec now mandates an XML configuration format.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t of open
questions.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
And there was minimal discussion on
it since then.
Can we issue a WGLC, and get it published?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
nor issues in the document as a result of reviews.
But as a matter of process, it seems very broken to me we require a WGLC in
order for people to review a WG document. This seems like a very problematic
change in the IETF process.
Alan DeKok.
_
mentors to inform end users about configuration /
incompatibility issues. RFC 9190 has a significant discussion of TLS alerts
already, and this document just references that.
> - "concatetation"
> "cloude"
> "changover"
> "deriviation"
> "authenticaton"
> "succeeed"
> "identies" (several places)
> "ciphersuite" (TLS uses the spelling cipher suite)
> "NewSessionTicketMessage" (NEW: NewSessionTicket message)
Fixed, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Feb 19, 2022, at 12:07 PM, Russ Housley wrote:
>
> For TLS 1.3, the message authentication code (MAC) is compute with the HMAC
> algorithm ...
Sure, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman
makes no sense to
have an outer identity of "@example.org". The authentication request
could then be routed to the "example.org" domain, which would have no
idea what to do with the credentials for "u...@example.com". At best,
the authentication request would be disc
On Feb 21, 2022, at 9:30 AM, Jan-Frederik Rieckers wrote:
> I have found some small typos.
Thanks. I've fixed them all.
I'll issue a new version at the end of the WGLC.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https:/
mentation developers that they always have to expect and
> require at minimum 0x00 octet over a TLSv1.3 tunnel when an EAP-based TLS
> method is about to skip tunnelled authentication.
Agreed. I'll add some text.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Windows 11 and TLS 1.3. But it didn't work historically.
I think it's a good idea to forbid (a) duplicate features, and (b) features
no one uses, and (c) features we're not sure have any value.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
identity would route the
packets to the hosting provider, who would then use the inner identity to
authenticate the user.
IMHO this practice should be strongly discouraged, for reasons discussed in
the draft.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
about 64K of data. That makes EAP unsuitable for anything other than the
most trivial of bootstrapping / management methods.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
nd,
even if the server has no intention of doing resumption.
If there are no objections or comments, I'll update the draft with some text
saying the above. I'll issue a new version next week.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
I'm sure that there are good reasons for using EAP here. But I can't help
but wonder if there's a better way that 3-4 different methods which all layer
on top of EAP.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
dardization. Ideally using existing networking protocols.
For example, RFC 8572 provides for similar tools (DNS SRV records + YAML /
RESTCONF) for provisioning devices. If it works for devices, why not do
something similar for end-user devices?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
rg-secure-bootstrapping/
>
> but that section hasn't happened yet.
I saw that. :(
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
etwork,
securely, and easily?
The answer I see is that the products are a collection of things from
different standards bodies, who often don't communicate well with each other.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
d DHCPv4.
Yes. I'm not sure that VLANs are a limited resource, or are difficult to
provision. GVRP has existed for a while...
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
aving renewals spread across time, but there are
> also disadvantages as it spreads the failure signal across time as well which
> makes it harder to see that there is a real problem.
Generally if people can't renew, the server should log errors, or the end
user device h
walled gardens / captive portals. It shouldn't be difficult
to extend that functionality with basic provisioning methods based on DNS /
web. Which the systems already have.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
values for attributes in general but prohibits for
> any declared types of the attributes.
Yes.
RADIUS is weird and terrible.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
an
authentication Type (4 or greater), the peer MAY respond with a Nak
indicating that it would prefer another authentication method that is
implemented by the RADIUS server, and not by the NAS. In this case,
the NAS SHOULD send an Access-Request encapsulating the received
EAP-Response/Na
in the same way as is done for FAST?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
received EAP-Response/Nak. This allows a peer to suggest another
> EAP method where the NAS is configured to send a default EAP
> type (such as MD5-Challenge) which may not be appropriate."
That looks good to me, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
+1
Other than that, they look OK, thanks.
> On Apr 1, 2022, at 1:16 AM, Bernard Aboba wrote:
>
> I think the note in eid6259 is now superfluous. Can we remove it?
>
> On Thu, Mar 31, 2022 at 10:09 PM Independent Submissions Editor (Eliot Lear)
> wrote:
> Corrected URLs below:
>
> On 0
On Mar 23, 2022, at 1:02 PM, Alan DeKok wrote:
> 2) the draft should be updated to add a note that when a supplicant sends
> PAP/CHAP for phase 2 of TTLS, the expected responses are:
>
> EAP-Success
> EAP-Failure
> Ongoing TLS negotiation, with a resumptio
As author, I support it.
Implementations are hostap, Windows, FreeRADIUS, and Radiator.
> On Jun 8, 2022, at 12:16 PM, Joseph Salowey wrote:
>
> This is the working group last call for draft-ietf-emu-tls-eap-types. You
> can find the document here:
>
> https://datatracker.ietf.org/doc/h
tion.
>
> I think it would be more clear to say that the inclusion of the logical Type
> makes the result method-specific.
OK. I'll update the text.
>
> Nit: The author on the title page should be "A. DeKok"
Fixed, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Jun 14, 2022, at 2:09 PM, Russ Housley wrote:
>
> I think you should just say that: TTLS, PEAP, and FAST each have
> method-specific application data.
Done.
> This resolves all of my concerns.
Thanks.
I'll push another version of the document at the end of the l
ocols to 'PAP, CHAP or MS-CHAP'.
>
> Paragraph 7 says '... do not provided protected ...'. Change 'provided' to
> 'provide'.
>
> Paragraph 7 also suggests replacements for PAP and CHAP to ensure protected
> indicators can be used. A replacement for MS-CHAP could be EAP-MSCHAP-V2 or
> possibly EAP-MD5?
A replacement for MS-CHAPv1 is MS-CHAPv2, or EAP-MSCHAPv2
>
> 8. References
> +++
> [PEAP-MPPE], [PEAP-PRF] and [PEAP-TK] point to different parts of [MSPEAP].
> It might be useful to clarify that this is the case in order to minimise the
> problem with broken links.
I'll add some clarifying text.
Thanks for the comprehensive review.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
gt;> the response from the EAP peer MUST be either
>>EAP-Success or EAP-Failure.
>>
> I though the Success and Failure messages are sent by the EAP server?
That was a typo, already addressed in a previous comment.
> 4. Section 4 says:
>
>
>> If either peer or server instead
>>initiates an inner tunnel method
>>
> I thought you have mandated the use of an inner tunnel method? So why the
> 'if'?
Resumption doesn't use an inner tunnel method. So the "if" is necessary.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
nner identity does contain an NAI realm, the inner
realm SHOULD be either an exact copy of the outer realm, or be a
subdomain of the outer realm. The inner realm SHOULD NOT be from a
different realm than the outer realm. There are very few reasons for
those realms to be different.
Alan
is draft is a work item of the EAP Method Update WG of the IETF.
>
>Title : TLS-based EAP types and TLS 1.3
> Author : Alan DeKok
> Filename: draft-ietf-emu-tls-eap-types-07.txt
> Pages : 20
> Date: 2022-07-05
>
I'll see also if I can have a first draft of a document defining @eap.arpa,
which will make unauthenticated EAP-TLS rather a lot more useful.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Can we make some progress on the document? There have been no substantive
comments for a while now.
The document is finished, the code is interoperable across multiple
implementations.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https
w is in the document and is up to date. I
think it's worth publishing. Given the lack of interest in FAST / TEAP with
TLS 1.3, I think that shouldn't be a barrier to publication.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
better to have guidance which is mostly correct (but might be
incorrect), than to give no guidance. That makes it effectively impossible for
implementors to upgrade to TLS 1.3.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
n is that they labels are somewhat generic
> (session key seed, session key generating function) which might lead to
> confusion.
It's a balance between that, and changing them to something different just
for TLS 1.3.
Given the minimal feedback from implementors, I'd be in
and it looks good to me. I have no comments.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
el - "EXPORTER: teap session key seed"
> Current draft label - "EXPORTER: session key seed"
>
> I think it would be helpful to make this change.
I'll fix the document to match RFC 7170. I think that's a good decision.
Alan DeKok.
ively broken out into its own section which I think it deserves to
> highlight "this is pointless folks, we have EAP-TLS for this".
I'll add text to TEAP and FAST. That seem simplest.
> I do agree with Alan though. Something has to point the direction that
> TEAP/EAP-FAST
On Sep 20, 2022, at 3:58 PM, Joseph Salowey wrote:
>
> I also notice that the document header says it updates RFC 5247 instead of
> RFC 4851.
Whoops. I've fixed that.
I'll take another pass over it, and issue a new rev tomo
AP or FAST.
The supplicant landscape is unfortunately rather limited.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ally meant to do here?"
>>
>> Do you have explicit text to suggest?
>
> I think your "That is, the MAC used is the MAC derived from the TLS
> handshake." covers this, thanks.
OK.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
What additions are there from EAP-TLS? Provisioning?
>> Note the lack of an Intermediate Result TLV, because the text states that
>> Intermediate Results are only required upon completion of an inner EAP
>> method.
I think that's reasonable.
be changed at this time.
If NIST deprecates SHA-1, then we can define PEAP (version n+1), and rely on
PEAP version negotiation to fix the issue.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
HA-1, which may be formally deprecated
in the near future.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
> On Nov 7, 2022, at 1:03 PM, John Mattsson wrote:
>
> Alan DeKok wrote:
> > It may be worth adding a one-sentence comment on the order of:
> >
> > Note that this derivation depends on SHA-1, which may be formally
> > deprecated in the
> > near fut
er demand for TEAP
in Q1 / Q2 2023. So it would be good to get consensus before going down any
particular path.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
several others to consider.
While I'm wary of extending the scope of a "fix errata" -bis document,
"making it work" is also a high priority.
So, yes. Adding more TLVs is fine. Current implementations don't use them,
but they could be updated wi
On Dec 1, 2022, at 12:41 AM, Eliot Lear wrote:
>
> No, but I would ask that we still have an interim to close the errata.
+1
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
small focus of this document, I hope it can move
forward quickly.
> Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-dekok-emu-rfc7170bis-00.txt
> Date: December 7, 2022 at 8:42:30 AM EST
> To: "Alan DeKok"
simpler to just push the fixes as individual commits.
These commits can then be discussed in the interim meetings. I can act as
secretary and make changes. I've also added Joe to the repo, so he can add
comments directly to each commit, or push c
neric "contains CSR stuff...", then could be
useful to add them, and note that detailed use-cases come later.
But my inclination is to just patch 7170 based on implementation experience,
and change nothing else. That way it can go out the door quickly, and be used
in shipping produ
ue that there's no need
to change the version.
Plus, if we change the version, then people have no idea what's currently
implemented. TEAP version 1 becomes an undocumented mess of unknowns.
As an implementor, I'm happy to declare RFC 7170 as irrelevant, and to issue
a new
not even sure what we'd do for TEAPv2. There isn't much point in
changing the key derivations. The current one is arguably suboptimal, but it
works. I wouldn't see a need to change it for something "better" in a TEAPv2.
So I'd like to know what
o say we're OK, and we can go ahead with 7170-bis, as TEAPv1.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
the previous version are the name change.
I'll work on getting the errata integrated into git either as individual
commits, or as individual PRs.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
too.
Thanks to Joe for pushing proposed fixes to the EMU GitHub account. I've
used those as some of the basis for these changes, along with suggested text
from the errata themselves.
Alan DeKok.
> On Dec 28, 2022, at 2:07 PM, internet-dra...@ietf.org wrote:
>
>
> A N
It's also important for implementors to write and
test the TLS 1.3 key derivations.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
The TEAP document is now hosted in the EMU WG repository:
https://github.com/emu-wg/rfc7170bis
> On Dec 30, 2022, at 11:02 AM, Joseph Salowey wrote:
>
> The EAP Method Update (emu) WG will hold a virtual interim meeting on
> 2023-01-04 from 09:00 to 10:00 America/Los_Angeles (17:00 to 18:00
required. If the peer or server does not
support a TLV marked 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
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
pe-TLV, Intermediate-Result-TLV and Cryptobinding-TLV".
I'll see if I can add something in.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
even there! The only place we found the order is explicitly defined is here:
> https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-chap/5a860bf5-2aeb-485b-82ee-fac1e8e6b76f
>
I'll update the reference.
> I created basic password authentication protocol state machine diagram and
> would like to share it for reference. Is there a standard way to share images
> in the WG?
In-line attachments might work? Or as a link to a web page?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
EAP conversation, and EAP Success or EAP
Failure when finishing one.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ng that receiving things you didn't
expect really means "send Result TLV indicating failure, and close the
connection".
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
I've pushed back all of the fixes I know about based on discussion on the
mailing list.
> On Dec 30, 2022, at 1:59 PM, Alan DeKok wrote:
>
> The TEAP document is now hosted in the EMU WG repository:
>
> https://github.com/emu-wg/rfc7170bis
>
>> On Dec 30, 2022
some text addressing the simpler issues.
As for registration policy, that will require a deeper WG discussion.
I'll see if I can add a template, too. But likely not before the interim
today.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Jan 4, 2023, at 3:20 AM, Eliot Lear wrote:
>
> This document is a complete specification, and as such should obsolete RFC
> 7170 (if approved).
Address in
https://github.com/emu-wg/rfc7170bis/commit/225cd8a0ce908febf12f1e4c16ab2eae3db3ce5f
A
update this document with TLS 1.3
issues.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
led as explicit errata.
There's a lot of commits there, but each one is relatively small. They're
also cross-link to either the official errata, or to the changes from the
"teap-errata" GitHub repo, or the commits have explanations as to why they've
been made.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
dding this
> would match the previous paragraph.
I agree. I've fixed it.
>
> Other minor suggestions and fixes
> +
> EAP-Response/Identity could be used as the common notation for the two uses
> in section 3.1.
Fixed.
> Section 6.1 has '... do not provided ...'. Remove 'ed'.
Fixed.
> Section 7 has a typo: tje
Fixed.
Thanks for the comments. Hopefully we can get an IETF last call soon.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
w Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the EAP Method Update WG of the IETF.
>
>Title : Tunnel Extensible Authentication Protocol (TEAP)
> Version 1
>Authors : Alan DeK
ou send fewer pixels, then scaled, they will be bigger on the
> recipient end. Share only a tab or a window, not your whole screen.
> (Mac has challenges here which not every browser seems to get right, due to
> the "window" including the File/Edit menus...)
> "
On Jan 7, 2023, at 4:59 AM, Alexander Clouter wrote:
>
> On Wed, 7 Dec 2022, at 13:48, Alan DeKok wrote:
>> * perhaps mentioning TLS 1.3?
>
> As the PEAP and EAP-TTLS RFCs do not there probably is no need to.
Well, those were written before TLS 1.3 came out. So they
501 - 600 of 800 matches
Mail list logo
