ic MAC
address, for example.
Another one is for roaming federations to simply ban EAP-PPT, if that method
is unable to satisfy their security / regulatory requirements.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
That's a bit of a head
> scratcher at the moment.
There simplest I think is that the TEAP server knows what the local network
looks like, and only sends the DHCP options when the RADIUS Access-Request
contains recognizably local NAS identific
Whatever the outcome, operators need to understand either how they can deal
> with abuse (Calling-Station-Id is not a good answer) or know that they cannot.
This is a separate problem, I think. Other EAP types have the same issue.
But it's a problem which should be addressed.
Alan
ome
> additionally special OOB protocol between the switchport and your policy
> server to communicate these DHCP assignments and make DHCP snooping work in
> practice. Of course the other option is to leave this at "use this only for
> assigning the WPAD server" :)
Y
ties could
also have interoperability problems.
The text could perhaps just say that the Identifier MUST be a realm-only NAI,
e.g. @example.com
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
On Jul 23, 2025, at 9:31 AM, Heikki Vatiainen wrote:
>
> On Thu, 19 Jun 2025 at 22:36, Alan DeKok
> wrote:
> ...
> Do implementations set / check the Nonce field as discussed above? Would
> it make sense to just ignore this field?
>
> See section '5.3. Compu
out why this was done in RADIUS
and not in Diameter instead. After a while, everyone realized that all of the
text was the same, and that requirement was dropped.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
chains?
* caching?
But overall, I think it's a good approach.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
al.
What happens when the chain is modified. Are the clients and servers
supposed to cache the chains? Doing so would help with performance, but it
could also affect the ability to update the chains.
Alan DeKok.
___
Emu mailing list -- emu@i
of the IETF.
>
> Title: The eap.arpa domain and EAP provisioning
> Author: Alan DeKok
> Name:draft-ietf-emu-eap-arpa-08.txt
> Pages: 24
> Dates: 2025-07-06
>
> Abstract:
>
> This document defines the eap.arpa domain for use only in Network
LD
err on the side of long delays between retrying the same provisioning
method to an EAP server. EAP peers MAY retry a given provisioning
method after a sufficiently long interval that the EAP server might
have implemented the provisioning method, e.g., at least a day, and
perhaps no mor
I support adoption of both drafts.
> On Jul 2, 2025, at 1:26 PM, Peter Yee wrote:
>
> The calls for adoption on these two drafts will end in one week. If we don't
> hear sufficient interest from working group participants, the documents
> simply will not be adopted. Now's the time to make yo
ctory
> for some reason, that's worth posting about too. Send your inputs to the
> mailing list soon. Thank you!
The document looks OK to me at first review. I don't have time to do a more
detailed review until the meeting in Madrid.
Alan DeKok.
__
7:40 AM, internet-dra...@ietf.org wrote:
>
> A new version of Internet-Draft draft-dekok-emu-teapv2-00.txt has been
> successfully submitted by Alan DeKok and posted to the
> IETF repository.
>
> Name: draft-dekok-emu-teapv2
> Revision: 00
> Title:Tunnel Extensib
ations set / check the Nonce field as discussed above? Would it
make sense to just ignore this field?
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
ailable. It is a work
> item of the EAP Method Update (EMU) WG of the IETF.
>
> Title: The eap.arpa domain and EAP provisioning
> Author: Alan DeKok
> Name:draft-ietf-emu-eap-arpa-07.txt
> Pages: 24
> Dates: 2025-06-04
>
> Abstract:
>
> Th
s successor" which seems stale even as it is
> written (EMU is "EAP Method Update", not "EAP"). Is this really the statement
> we want to make?
I think so. That way others who have opinions can jump in.
> ### pre-defined
>
> Both "pre-de
s not include a trailing '.', and permits
ALPHA / DIGIT / UTF8-xtra-char plus a few punctuation marks.
> I'll note that I've spent this entire review essentially on one sentence in
> this draft.
That's fine, thanks.
Alan DeKok.
___
ed earlier in the document:
"Servers SHOULD rate-limit provisioning attempts. ..."
I'll add a paragraph requiring that peers rate limit their attempts, too.
> 4- Section 6.2.1:
>
> "The following table gives the initial values for this table." -> The table
> is
> not displayed correctly in this section, and it is missing a caption.
I'll fix that, thanks.
> Nits:
Fixed, thanks.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
etf.org wrote:
>
> Internet-Draft draft-ietf-emu-rfc7170bis-22.txt is now available. It is a work
> item of the EAP Method Update (EMU) WG of the IETF.
>
> Title: Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Author: Alan DeKok
> Name:draft-ietf-emu-
quot;_function.eap.arpa".
I'll take a pass at updating the document. There has been significant
feedback from outside of EMU for it. This is unusual, but welcome.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
I've pushed the changes.
> On May 15, 2025, at 6:16 PM, Benjamin Kaduk wrote:
>
> Hi Alan,
>
> Could you push your git branch to github? I'm staging some editorial
> suggestions as I do my secdir review and I noticed that the version on
> github seems to only be the -05.
>
> Thanks,
>
> Be
rdless authentication
> schemes such as the CTAP2 version of FIDO2."
>
> We could make some modifications to this if necessary. We also have some
> items for provisioning.
>
> Alan DeKok.
>
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
m/emu-wg/charter/pull/4/files and indicate if you support
> the charter revision. You may comment on the charter by responding to this
> thread or commenting on the pull request.
The charter updates describe one privacy-preserving proposal. Given the
EAP-FIDO draft, should we allow for
If EMSK is not essential, TEAPv2 could then be the version that clearly
> defines how EMSK is used.
Yes.
Even if EMSK is essential, it's worth documenting TEAPv1. And we can't
change TEAPv1 without declaring that existing deployments are not compliant.
So we pretty much have to publ
so note that TEAP doesn't define implicit challenges for EAP-MSCHAPv2,
while TTLS does. I suspect that it would be a good idea to do that, too.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
> 1) declare the MSFT behaviour TEAPv0. Crypto-Binding contains only the
>> MSK Compound MAC, the EMSK Compound MAC is always zero
>
> Is version 0 even valid?
> What do these old versions declare as their version?
Sorry, TEAPv1.
So TEAPv1 is "MSK Compoun
be required to upgrade to TEAPv2, but people who do upgrade will
be able to use the EMSK Compound MAC.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
ive the EMSK Compound MAC. Write it down.
Test it with implementations.
3) issue TEAPv1 which defines the EMSK Compound MAC, and uses it in the
Crypto-Binding TLV.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
+1
> On Feb 27, 2025, at 2:09 PM, Peter Yee wrote:
>
> For the record, I think that charter statement is fine. The sole change I
> would suggest is s/user and/user, and/ . It’s an awfully long, uninterrupted
> sentence otherwise.
> -Peter
> On 2/27/25, 10:13
spect the answer is that everyone uses the MSK Compound-MAC, and ignores
the EMSK Compound-MAC. If so, it needs to be documented.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
to get the final draft
before the cutoff for IETF 122.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
of the EAP Method Update (EMU) WG of the IETF.
>
> Title: Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Author: Alan DeKok
> Name:draft-ietf-emu-rfc7170bis-21.txt
> Pages: 120
> Dates: 2025-02-06
>
> Abstract:
>
> This docum
ng each individual change as a
separate git commit. The hope is that the resulting series of commits will be
easy to understand and to review.
So I had hoped that 7170bis was done. But in the interest of improving the
document to increase interoperability, it looks like it needs
any any" - remove duplicate "any"
Done.
> I find the following sentences a bit weird. I think it can just be removed:
>
> We now discuss the NAI format in more detail. We first discuss
> the eap.arpa realm, and second the use and purpose of the
> u
y works, sort of". And then immediately publish TEAPv2, which would
more clearly define the cryptographic derivations.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
On Jan 7, 2025, at 10:55 AM, internet-dra...@ietf.org wrote:
>
> Internet-Draft draft-ietf-emu-rfc7170bis-20.txt is now available. It is a work
> item of the EAP Method Update (EMU) WG of the IETF.
>
> Title: Tunnel Extensible Authentication Protocol (TEAP) Version 1
>
I do not know of any IPR for this document. I'm OK with publishing it.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
pport keys generation. However such a sentence could be
> off-putting implementers.
I'll clarify. Jouni also pointed out that because EAP-TLS works, it is
highly likely that other EAP types work so long as they derive MSK and EMSK.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
heir implementation
matches this behaviour, then we're good to go. I fully expect this to be the
case, because all implementations appear to be interoperable. But it would be
good to get explicit feedback from the implementors that this is the case.
Alan DeKok.
the challenge and the issued token to
> send to the server to verify.
>
>
> Some initial comments on the document
> - I dont think EAP-PPT generates key material, it requires the tunnel method
> to generate key material as the pr
connection. That can easily be
done, and is really just an implementation detail.
Perhaps CoAP has issues with one CoAP client doing multiple authentications
at the same time. But that's a CoAP issue, and has nothing to do with EAP.
Alan DeKok.
__
ward FIDO traffic to my web server. But your EAP
server can't forward traffic to my web server.
So is this an attack we care about? It may be sufficient to say "attacks
within your organization are possible, but the solution to that is to police
y
o binding issues aren't relevant. i.e. the client can just use the
servers challenge.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
phic binding. That exchange could stay inside of EAP-FIDO, and
wouldn't have to affect any FIDO exchanges.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
#x27;t support them
MUST be safe.
The second priority is to ensure that the provisioning workflows will always
work, and do something useful.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
> tls-pok-dpp.eap.arpa.
> I don't think that there are any options other than anonymous@ or
> empty-string.
As per Heikki's comment, it should be tls-pok-...@method.eap.arpa. i.e.
tls-pok-...@teap.eap.arp
Alan DeKok.
___
Emu mai
had determined that it couldn't start
> provisioning at this time. Instead of being helpful, the server should be
> clear that this authentication can not continue and must fail.
If the server can't authenticate, it just sends EAP Failure.
Alan DeKok.
_
bout
> eap.arpa probably shouldn't allow this to happen.
Agreed.
> There's more about NAKs on the list in messages discussing
> draft-ietf-emu-bootstrapped-tls-06 comments, including comments Alan is
> considering for this draft.
I'll try to publish a new draft early next week.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
Perhaps:
# EAP Peers
An EAP session begins with the peer receiving an initial
EAP-Request/Identity message. An EAP peer supporting this
specification MUST examining the identity to see if it uses the eap.arpa
realm. If not, the EAP peer MUST process the request normally.
The EAP peer MUST ch
+1 to all of this.
I'll add some notes to the eap.arpa document to raise issues brought up here:
* EAP type selection can be done by examining the provisioning NAI
* NAKs should be handled specially for provisioning NAIs
* There is no method to NAK a particular kind of provisioning.
e.g.
+1
> On Sep 24, 2024, at 5:39 PM, Eliot Lear wrote:
>
> Signed PGP part
> I think this draft ready to go as well. I know that Owen has prototyped it,
> and I'd like to see it advance.
>
> Eliot
>
> On 23.09.2024 21:01, Peter Yee wrote:
>> Draft-ietf-emu-bootstrapped-tls has two days left o
EAP Method Update (EMU) WG of the IETF.
>
> Title: The eap.arpa domain and EAP provisioning
> Author: Alan DeKok
> Name:draft-ietf-emu-eap-arpa-02.txt
> Pages: 18
> Dates: 2024-08-12
>
> Abstract:
>
> This document defines the eap.arpa dom
o note that the username portion defines
the _type_ of provisioning being done. Different usernames are different kinds
of provisioning. And empty usernames are different from non-empty usernames.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
On May 10, 2024, at 6:48 PM, Haoyu Song via Datatracker
wrote:
>
> Reviewer: Haoyu Song
> Review result: Ready with Nits
>
> I’m the assigned INTDIR reviewer for this document. This document defines the
> Tunnel Extensible Authentication Protocol V1 which obsoletes RFC7010.
>
> I couldn’t find
rk
> item of the EAP Method Update (EMU) WG of the IETF.
>
> Title: The eap.arpa domain and EAP provisioning
> Author: Alan DeKok
> Name:draft-ietf-emu-eap-arpa-01.txt
> Pages: 17
> Dates: 2024-07-30
>
> Abstract:
>
> This document defines
anges per sessions, the use of
resumption will tie two sessions together
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
m of the EAP Method Update (EMU) WG of the IETF.
>
> Title: Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Author: Alan DeKok
> Name:draft-ietf-emu-rfc7170bis-19.txt
> Pages: 110
> Dates: 2024-06-07
>
> Abstract:
>
> This document de
ot; list for too long.
> Alas, I had no opportunity to check whether all nits from
> https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-17.txt
> are false positive.
I'll double-check.
Alan DeKok.
_
On May 29, 2024, at 2:29 PM, Warren Kumari via Datatracker
wrote:
> My primary remaining comment is that Abstract for the document briefly should
> say *how* it updates RFC9427 - that way when someone reads RFC9427 they need
> only check this new document's Abstract to know if they need to read t
ype Type
> Codes’
> registries for new registrations and updates there registries with a NOTE:”
Will do.
> ** idnits reports:
>
> -- Obsolete informational reference (is this intentional?): RFC 5226
> (Obsoleted by RFC 8126)
Updated, thanks.
Alan DeKok.
___
Yes.
> '[]' I have no idea, in TLS 1.3 it would signify encrypted messages, but
> clearly that can't be the case here (TLS server_key_exchange can't be
> encrypted).
TBH that's left over from 7170, and I'm not entirely sure.
> I like the ASCII art in Section C.1-C.10, not so much in C.11 on
> because it is harder to see which way the arrows point (less white space).
That diagram was a later addition. I'll see if I can find time to re-do
the diagrams manually before AUTH 48.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
hat allow doing this. Maybe, for example, IOT experts
> could say if they see use for TEAP/PEAP/EAP-TTLS used for tunnelling SIM
> based EAPs?
Sure. I'll update the document.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
plicit that
> this is data used by EAP?
The rest of the document discusses how the EAP server handles the inner
tunnel data, so I think it's already explicit that the data is handled by EAP.
Alan DeKok.
___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
> The options are send one or the other, depending on the conditions or just
> send one regardless of the conditions, perhaps the answer is to just send
> Result TLV regardless?
The document already mandates sending a Result TLV to indicate the final
result of authentication, so I t
On May 20, 2024, at 8:12 PM, Orie Steele wrote:
>
> On Mon, May 20, 2024 at 6:24 PM Alan DeKok
> wrote:
>>
>> "It MUST only send a NAK TLV for a TLV which is marked mandatory."
>>
>
> It MUST send a NAK TLV for any TLV which is marked mandatory but
PKCS#10 TLV (see Section 4.2.17). The TEAP server
> issues a
> 1232 Simple PKI Response using a PKCS#7 [RFC2315] degenerate (i.e.
> 1233 unsigned) "Certificates Only" message encoded into the body of a
> 1234 PKCS#7 TLV (see Section 4.2.16), only after an inner
n479
>
> Wikipedia has more info about its history and pointers to the first commits
> from 10+ years ago:
> https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol#EAP-TLS
>
> I haven't seen any use of "WFA-UNAUTH-TLS&
U) WG of the IETF.
>
> Title: Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Author: Alan DeKok
> Name:draft-ietf-emu-rfc7170bis-16.txt
> Pages: 111
> Dates: 2024-03-26
>
> Abstract:
>
> This document defines the Tunnel Extensib
e.g.
provisioning.t...@eap.arpa
instead of
provision...@teap.eap.arpa
I think the second looks clearer to me.
Alan DeKok,
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
>
> PS: There was also an issue that the current draft recommends Expert Review
> for assignment of new values but then also expects RFCs: "The intention is
> that any non-prefix allocation will be accompanied by a published RFC.". I
> think it will be beneficial to have &q
unauthenticated mode since 2008 (RFC 5216 Section
2.1.1). But there's been no way to actually use it.
Hopefully this set of documents will address that issue.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
pa
document, too.
* define an eap.arpa domain for use with a number of proposed provisioning
methods.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
OR
> messages sent in EAP-FIDO.
Is that fixed, or negotiated?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
to be explicit. If we have an attribute that says "MUST be of
> length one", some vendor will ignore it, on the sending or receiving side.
> How do we deal with two PKIDs? do we take the first one? The last one? Do we
> abort completely?
> I find it better to be explicit,
ate versions.
An alternative would be to do the version negotiation inside of the TLS
tunnel. That's also imperfect, but at least gives EAP-FIDO complete control
over all aspects of the protocol.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
is problem; sort of like
> GREASE...but to fix an insecurity instead.
I think that changes existing implementations. Unless the recommendation is
for each end to add a dummy Outer-TLV which implementations are *known* to
ignore.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
x27;t
> send it by default to unauthenticated servers, but offer a way for the user
> to override that default?
I believe that Identity-Hint is not useful for server unauthenticated
provisioning, and therefore should not not be used in that
On Mar 1, 2024, at 10:21 PM, David Mandelberg via Datatracker
wrote:
>
> (nit) If I understand the TEAP version negotiation and Crypto-Binding
> correctly, the negotiated version is not cryptographically verified until
> either (1) after the first inner method is completed or (2) just before the
[THIS-DOCUMENT]
Fixed.
>
> Protection against Man-in-the-Middle Attacks
>
> Maybe rename to "on-path attacks" ?
Fixed.
> Appendix C.4 should clarify the TLS version used (1.2). Should it be
> changed to use a TLS 1.3 example?
I think so, yes. I'll have to dig into that. I don't think I can get that
updated today before the deadline.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
This update includes guidelines for DNS operators and implementors.
> Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-dekok-emu-eap-arpa-01.txt
> Date: February 25, 2024 at 5:23:32 PM EST
> To: "Alan DeKok&
I support adoption.
I'll review it for any general EAP issues. I have less confidence in my
ability to review any cryptography.
> On Nov 29, 2023, at 12:13 PM, Peter Yee wrote:
>
> This is an adoption call for EAP-EDHOC (draft-ingles-eap-edhoc) [1].
> This draft was originally briefed in
orks for the web, email,
and pretty much every other TLS-based protocol. Why not EAP?
I would only add to that that any such method should be limited to just
sending a clear-text password. There's no reason to continue allowing MS-CHAP
and CHAP.
Alan DeKok.
_
IDO alliance is pushing this is actually a
> great step, because the FIDO Passkey that is already provisioned for logging
> into the account in the web can now simply be used for network access as well.
That is my hope.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
on via FIDO as discussed
* provisioning of FIDO credentials
* de-provisioning of credentials.
The last one is hard, as how do you de-provision credentials if you've
deleted them, and you can't prove who you are?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
is simple enough that the end user can configure it manually. And
critically, cannot configure it *incorrectly*. It's either secure and it
works, or it's insecure and it doesn't work.
We've had ~20+ years of relying on end users to carry the burden of
supplicant configuratio
rrelate users
> to Chromebooks)
Oh my.
I can't publicly say what I would like, so I will leave it at that.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
exact host name doesn't matter.
The server certificate should be signed with a CA known to the supplicant.
And it doesn't matter which CA.
I think that the discussion here shows that pinning a server cert or CA cert
will create more problems than it solves.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
g tricky, but I think
> the idea also has merit.
Shades of TEAP!
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
e
can just say that the EAP certificate should be issues by the same (or
equivalent CA) to the one which was used to provision the initial FIDO
credentials.
In practice, this means WebPKI most of the time. :)
Alan DeKok.
___
Emu mailing li
So I see this as two new methods:
1) tunnelled FIDO - for use in TTLS, PEAP, or other TLS-based EAP methods.
2) TLS-based method with tunnelled FIDO - it can make new / stronger
requirements on CA validation, server identity, etc.
We could just ban the use of tunnelled FIDO in TTLS / PEAP. But I'm not sure
that's practical. It's likely safer to just define TTLS + tunnelled FIDO.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
It looks good as a first draft. Some first draft comments:
I would suggest that the default should be to using the Web PKI for server
authentication, unless there's a client configuration which says to use a
different CA. This behavior means that configuring EAP-FIDO for a domain is
simpl
ed EAP-TLS
* get the domain name from the server
* then use EST (RFC7030) to connect to a well-known URI for that network, and
do some more work.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Sep 10, 2023, at 6:56 PM, Alan DeKok wrote:
> There have been long discussions about not tying EAP to DHCP. I forget
> which RFC it is, but there's an IAB architectural document which says this is
> a bad idea.
https://www.rfc-editor.org/rfc/rfc5505.html
The use o
hink the supplicant should know what kind of access it's getting. This is
also a signal to the RADIUS server as to what kind of authorization to send to
the NAS / switch.
In contrast, if there's only one kind of on-boarding access, authorization
ha
e (EMU) WG of the IETF.
>
> Title: Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Author: Alan DeKok
> Name:draft-ietf-emu-rfc7170bis-14.txt
> Pages: 108
> Dates: 2023-09-04
>
> Abstract:
>
> This document defines the Tunn
st
posted an "eap.arpa" draft now.
It's still very rough, but the idea is "use someth...@eap.arp". And then
fill in some suggestions.
A new version of Internet-Draft draft-dekok-emu-eap-arpa-00.txt has been
successfully submitted by Alan DeKok and posted to the
IETF reposi
ble". So if
an implementation doesn't use EMSK, it's violating the spec.
Plus, all existing implementations use EMSK. So anyone who doesn't do that
won't interoperate.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
(inner method, something else). Because it appears
>> to be an inner method, also add text to section 3.11. where the use of the
>> two TLV types is required.
> Agree. It's an inner method, as indicated in Section 4.3.2.
I'll a
On Aug 26, 2023, at 3:47 PM, Alexander Clouter wrote:
> I have read through the document and think it is "good to go", post nit
> combing...
Fixed, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
1 - 100 of 800 matches
Mail list logo
