Hi Michael,
You know homenet details much better. The only point I was trying to
make is that it is possible to have sub-domains under a special use
domain. "home.arpa" is one example. "e164.arpa" from RFC 6116
(https://www.rfc-editor.org/rfc/rfc6116.html) seems to be another example.
Mohit Sethi wrote:
> As far as I can tell, we will not be the first ones using such a
> scheme. ".home.arpa." defined in RFC 8375
> (https://www.rfc-editor.org/rfc/rfc8375.html) allows sub domains. It says:
> "For an administrative domain that uses subdomains of 'home.arpa.',
As far as I can tell, we will not be the first ones using such a scheme.
".home.arpa." defined in RFC 8375
(https://www.rfc-editor.org/rfc/rfc8375.html) allows sub domains. It
says: "For an administrative domain that uses subdomains of
'home.arpa.', such as a homenet, the recursive resolvers
On Mar 22, 2024, at 1:58 PM, Michael Richardson wrote:
> I think its an IAB question. IANA with implement whatever we ask for.
> It would be EMU's Expert Reviewers that would decide, I guess.
> It's late in the week to pigeon hole someone, but ... maybe we can find
> someone.
OK.
> Is a
Alan DeKok wrote:
> 1. Instead of servers deciding the EAP method based on the username
>part of the NAI, the EAP method could be decided based on the sub domain
>under eap.arpa in the realm portion of the NAI. Thus a peer wanting to
>be provisioned would use
On Mar 21, 2024, at 11:30 PM, Mohit Sethi wrote:
>
> I would like to support the adoption of the document with two caveats based
> on my deployment experience thus far. Obviously, Alan and Heikki have much
> more expertise and experience than me but just providing a data point:
>
> 1. Instead
I would like to support the adoption of the document with two caveats
based on my deployment experience thus far. Obviously, Alan and Heikki
have much more expertise and experience than me but just providing a
data point:
1. Instead of servers deciding the EAP method based on the username
On Fri, 8 Mar 2024 at 08:38, Peter Yee wrote:
> We are particularly interested in hearing from parties who are
> willing to review the specification. So, if you've got interest in
> seeing the work adopted, please formalize that by responding
> to the EMU mailing list with your position.
>
I
On Mar 13, 2024, at 9:51 AM, Michael Richardson wrote:
>>> I don't think it's that straight forward. For Enterprise-WiFi we
>>> still need cryptographic keys for the WiFi 4-way handshake, so
>>> establishing a TLS-Tunnel is needed to derive the WPA keys.
We also need it for MacSec on wired
Alexander Clouter wrote:
>>> On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote:
My understanding here is that the EAP server and client will not
authenticate each other in EAP-TLS, and all the authentication will
be done in the " captive portal ". So why recommend
On Tue, 12 Mar 2024, at 14:45, Jan-Frederik Rieckers wrote:
> On 12.03.24 13:45, Alexander Clouter wrote:
>> On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote:
>>> My understanding here is that the EAP server and client will not
>>> authenticate each other in EAP-TLS, and all the authentication
On 12.03.24 13:45, Alexander Clouter wrote:
On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote:
My understanding here is that the EAP server and client will not
authenticate each other in EAP-TLS, and all the authentication will be
done in the " captive portal ". So why recommend EAP-TLS as a
On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote:
> My understanding here is that the EAP server and client will not
> authenticate each other in EAP-TLS, and all the authentication will be
> done in the " captive portal ". So why recommend EAP-TLS as a
> provisioning method? Just send the
AN
-Original Message-
From: Emu On Behalf Of Peter Yee
Sent: Friday, March 8, 2024 6:38 AM
To: emu@ietf.org
Subject: [Emu] Adoption call for eap.arpa
This is an adoption call for the eap.arpa Internet-Draft
(draft-dekok-emu-eap-arpa). This is an ancillary draft that Alan DeKok briefed
On Thu, 7 Mar 2024, at 22:38, Peter Yee wrote:
> The deadline for feedback is March 21st. Yes, that's during IETF
> 119 but after the EMU time slot, so hopefully you will have
> formed an opinion by then, if not sooner. We hope to hear
> from lots of you!
>
> 1)
I think this work is useful, emu is the right WG for that, so I'm in
favor of adopting.
Cheers,
Janfred
On 07.03.24 23:38, Peter Yee wrote:
This is an adoption call for the eap.arpa Internet-Draft
(draft-dekok-emu-eap-arpa). This is an ancillary draft that Alan
DeKok briefed during the Prague
I've read draft-dekok-emu-eap-arpa, I think it important step in getting
a number of other efforts underway. Please adopt.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
This is an adoption call for the eap.arpa Internet-Draft
(draft-dekok-emu-eap-arpa). This is an ancillary draft that Alan
DeKok briefed during the Prague (IETF 118) meeting. Seeing as
it primarily exists as a forward-looking extraction of certain
descriptive material and IAB .arpa domanrequests
18 matches
Mail list logo
