Re: [Emu] eap.arpa domain in draft-ietf-emu-bootstrapped-tls

[Alan DeKok]

On Sep 11, 2023, at 12:38 PM, Michael Richardson  wrote:
> There is no connection here.
> EAP(nobody) gets you a useable L2.
> L2 makes DHCP possible.  There is no link, and they are not tied.

  I suspect the kind of provisioning you need is related to the kind of network 
access you get.

  The alternative would be to just define how "server unauthenticated EAP-TLS" 
works, and then punt the problem elsewhere.

  i.e. "You're on _some_ net, with _some_ kind of properties.  It's up to you 
to figure out what to do next".

> When you write this, what I am hearing: the end user has to know everything
> about the network they are joining.  And that's exactly what I think we are
> trying to avoid.

  I mostly agree.  The user shouldn't know.  But the supplicant has to know 
what it wants to do.

  The alternative is for the supplicant to know what it's doing (signalling via 
EAP), and then somehow forget about that when it has network access.

  Or, the supplicant doesn't know it's doing provisioning, gets on the network 
somehow, and then the system receives a DHCP packet with a captive portal 
option.

  The system won't know why that option was received.  All it can do is punt 
the user to the captive portal, and let the human deal with things.

>> In contrast, if there's only one kind of on-boarding access,
>> authorization has to be done through DHCP which has much more limited
>> capabilities for that.
> 
> There are possibly many different ways depending upon where you open the lid
> of your laptop, phone, chromebook, personal IoT device.

  DHCP doesn't do VLANs, and VLANs are widely used in enterprise environments 
to isolate traffic.

  I think that requiring only DHCP makes certain use-cases impossible.  
Allowing DHCP, but also allowing something with EAP will have the widest 
possible usability.

  If we allow some kind of signalling via EAP, then we can also say what the 
local network should look like.  e.g.:

* do server unauthenticated 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

Re: [Emu] eap.arpa domain in draft-ietf-emu-bootstrapped-tls

[Michael Richardson]

Alan DeKok  wrote:
>> I think that this is a mistake to be so specific.
>> I don't think the supplicant should know/care, at this point, what kind 
of
>> access it is going to get.  I liked what we we had done with 
eap-onboarding
>> where you get limited network, and then if DHCP says, via the DHCP option
>> (or the RA option) that there is a captive portal, then it should do 
that.
>> Or, it could say do RFC8995 (BRSKI) via GRASP announcement.
>> Or...

> 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.

There is no connection here.
EAP(nobody) gets you a useable L2.
L2 makes DHCP possible.  There is no link, and they are not tied.

> I think 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.

When you write this, what I am hearing: the end user has to know everything
about the network they are joining.  And that's exactly what I think we are
trying to avoid.

> In contrast, if there's only one kind of on-boarding access,
> authorization has to be done through DHCP which has much more limited
> capabilities for that.

There are possibly many different ways depending upon where you open the lid
of your laptop, phone, chromebook, personal IoT device.




--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] eap.arpa domain in draft-ietf-emu-bootstrapped-tls

[Alan DeKok]

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 of @eap.arpa is explicitly for situations where network access is 
possible only via EAP.   The users authorization and type of network access 
depends on their identity, which is a common pattern in EAP.

  The use of the DHCP Captive Portal URI option is independent from EAP.  It 
may be used in conjunction with EAP, but that shouldn't be a requirement.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] eap.arpa domain in draft-ietf-emu-bootstrapped-tls

[Alan DeKok]

On Sep 10, 2023, at 6:38 PM, Michael Richardson  wrote:
> So, this replaces draft-richardson-emu-eap-onboarding-03
> which would use onboard...@eap.arpa.  (Hmm. I keep thinking it was going to
> be "nob...@eap.arpa")

  This document defines the @eap.arpa and the associated registry.  It doesn't 
define how entries in the registry are used.  There's a trivial example, but 
it's not fleshed out.

>> HTML: https://www.ietf.org/archive/id/draft-dekok-emu-eap-arpa-00.html
> 
> You use por...@eap.arpa here.
> 
> I think that this is a mistake to be so specific.
> I don't think the supplicant should know/care, at this point, what kind of
> access it is going to get.  I liked what we we had done with eap-onboarding
> where you get limited network, and then if DHCP says, via the DHCP option
> (or the RA option) that there is a captive portal, then it should do that.
> Or, it could say do RFC8995 (BRSKI) via GRASP announcement.
> Or...

  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.

  I think 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 
has to be done through DHCP which has much more limited capabilities for that.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] eap.arpa domain in draft-ietf-emu-bootstrapped-tls

[Michael Richardson]

Alan DeKok  wrote:
> On Aug 30, 2023, at 6:29 AM, Owen Friel (ofriel) 
 wrote:
>>
>> Hi EMU Chairs,
>>
>> I was looking to see if any minor updates are needed to 
draft-ietf-emu-bootstrapped-tls-03 before IETF 118 and WGLC.
>>
>> There was one outstanding action from IETF 117:
>>
>> Do we want to say there is an eap.arpa domain? Yes, but
>> not clear this draft is place to do that. Chairs to ask IAB to do
>> this.

> I had discussed this off-line with the chairs, and they were waiting for 
me to do something.  I've bene trying to get TEAP out of the way, but I've just 
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.

So, this replaces draft-richardson-emu-eap-onboarding-03
which would use onboard...@eap.arpa.  (Hmm. I keep thinking it was going to
be "nob...@eap.arpa")

> HTML: https://www.ietf.org/archive/id/draft-dekok-emu-eap-arpa-00.html

You use por...@eap.arpa here.

I think that this is a mistake to be so specific.
I don't think the supplicant should know/care, at this point, what kind of
access it is going to get.  I liked what we we had done with eap-onboarding
where you get limited network, and then if DHCP says, via the DHCP option
(or the RA option) that there is a captive portal, then it should do that.
Or, it could say do RFC8995 (BRSKI) via GRASP announcement.
Or...

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] eap.arpa domain in draft-ietf-emu-bootstrapped-tls

[Peter Yee]

Alan,
I've also sent an inquiry to the IAB on the matter to see if they have 
any thoughts. I'll post to the list if they come back with any opinions. Your 
draft will also be helpful either way as we can decide whether to incorporate 
their thoughts (if they've some concrete and coherent to offer) or we can use 
the draft as the start of a wider discussion on the topic. Thanks for posting 
it!

-Peter

On 8/30/23, 10:48 AM, "Emu on behalf of Alan DeKok" mailto:emu-boun...@ietf.org> on behalf of al...@deployingradius.com 
> wrote:


On Aug 30, 2023, at 6:29 AM, Owen Friel (ofriel) 
mailto:40cisco@dmarc.ietf.org>> wrote:
> 
> Hi EMU Chairs,
> 
> I was looking to see if any minor updates are needed to 
> draft-ietf-emu-bootstrapped-tls-03 before IETF 118 and WGLC.
> 
> There was one outstanding action from IETF 117:
> 
> Do we want to say there is an eap.arpa domain? Yes, but
> not clear this draft is place to do that. Chairs to ask IAB to do
> this.


I had discussed this off-line with the chairs, and they were waiting for me to 
do something. I've bene trying to get TEAP out of the way, but I've just 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 repository.


Name: draft-dekok-emu-eap-arpa
Revision: 00
Title: The eap.arpa domain and EAP provisioning
Date: 2023-08-30
Group: Individual Submission
Pages: 13
URL: https://www.ietf.org/archive/id/draft-dekok-emu-eap-arpa-00.txt 

Status: https://datatracker.ietf.org/doc/draft-dekok-emu-eap-arpa/ 

HTML: https://www.ietf.org/archive/id/draft-dekok-emu-eap-arpa-00.html 

HTMLized: https://datatracker.ietf.org/doc/html/draft-dekok-emu-eap-arpa 





Abstract:


This document defines the eap.arpa domain as a way for EAP peers to
signal to EAP servers that they wish to obtain limited, and
unauthenticated, network access. EAP peers leverage user identifier
portion of the Network Access Identifier (NAI) format of RFC7542 in
order to describe what kind of provisioning they need. A table of
identifiers and meanings is defined.






The IETF Secretariat


___
Emu mailing list
Emu@ietf.org 
https://www.ietf.org/mailman/listinfo/emu 





___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] eap.arpa domain in draft-ietf-emu-bootstrapped-tls

[Alan DeKok]

On Aug 30, 2023, at 6:29 AM, Owen Friel (ofriel) 
 wrote:
> 
> Hi EMU Chairs,
>  
> I was looking to see if any minor updates are needed to 
> draft-ietf-emu-bootstrapped-tls-03 before IETF 118 and WGLC.
>  
> There was one outstanding action from IETF 117:
>  
> Do we want to say there is an eap.arpa domain? Yes, but
> not clear this draft is place to do that. Chairs to ask IAB to do
> this.

  I had discussed this off-line with the chairs, and they were waiting for me 
to do something.  I've bene trying to get TEAP out of the way, but I've just 
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 repository.

Name: draft-dekok-emu-eap-arpa
Revision: 00
Title:The eap.arpa domain and EAP provisioning
Date: 2023-08-30
Group:Individual Submission
Pages:13
URL:  https://www.ietf.org/archive/id/draft-dekok-emu-eap-arpa-00.txt
Status:   https://datatracker.ietf.org/doc/draft-dekok-emu-eap-arpa/
HTML: https://www.ietf.org/archive/id/draft-dekok-emu-eap-arpa-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-dekok-emu-eap-arpa


Abstract:

  This document defines the eap.arpa domain as a way for EAP peers to
  signal to EAP servers that they wish to obtain limited, and
  unauthenticated, network access.  EAP peers leverage user identifier
  portion of the Network Access Identifier (NAI) format of RFC7542 in
  order to describe what kind of provisioning they need.  A table of
  identifiers and meanings is defined.



The IETF Secretariat

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] eap.arpa domain in draft-ietf-emu-bootstrapped-tls

[Peter Yee]

That one’s on me, gents. I have the action to inquire and will do so ASAP.

 

    -Peter

 

On 8/30/23, 3:29 AM, "Owen Friel (ofriel)"  wrote:

 

Hi EMU Chairs,

 

I was looking to see if any minor updates are needed to 
draft-ietf-emu-bootstrapped-tls-03 before IETF 118 and WGLC.

 

There was one outstanding action from IETF 117:

 

Do we want to say there is an eap.arpa domain? Yes, but

not clear this draft is place to do that. Chairs to ask IAB to do

this.

 

Is there any clarity on this yet?

Thanks,

Owen+Dan

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] eap.arpa domain in draft-ietf-emu-bootstrapped-tls

[Owen Friel (ofriel)]

Hi EMU Chairs,

I was looking to see if any minor updates are needed to 
draft-ietf-emu-bootstrapped-tls-03 before IETF 118 and WGLC.

There was one outstanding action from IETF 117:

Do we want to say there is an eap.arpa domain? Yes, but
not clear this draft is place to do that. Chairs to ask IAB to do
this.

Is there any clarity on this yet?
Thanks,
Owen+Dan
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu