Re: [Emu] BRSKI-TEAP vs regular connection (was Re: EAP questions ...)

2020-01-16 Thread Michael Richardson

Eliot Lear (elear)  wrote:
>> On 15 Jan 2020, at 16:10, Michael Richardson  
wrote:
>>
>>
>> Eliot Lear (elear)  wrote:
 Owen, do we have a need to recognize that a device needs to perform
 onboarding again after a movement?

 i.e. device A enrolls on network 1, gets an LDevID usable on network
 1, uses that with EAP-FOOBAR.

 device A then is moved to network 2, it tries to use same LDevID,
 receives an error and then recognizes that it needs to perform another
 enrollment.
>>
>>> I think that is up to the device manufacturer and relates to a number
>>> of factors, such as whether the device is mobile, whether it has a
>>> reset button, the nature of the device, privacy considerations, whether
>>> there are federated capabilities on the device, etc.
>>
>> I can see that some of these are important to the device.
>> The device may have reasons why it would like to enroll again, but I 
think
>> the question is more about when the network recognizes that it does not 
need
>> to enroll again.
>> An example would be a device which was originally enrolled with 
BRSKI-TEAP,
>> but is then provided with roaming credentials (EDU-ROAM).
>>
>> How would it know it was on network 2?

> Ah.  I misread your note the first time.  The example of 2 is precisely
> eduroam, and this becomes a matter of configuration.  We were talking
> about this at one point, and there is a need to configure a realm as
> part of all of this.  That is something that could be easily be
> included in TEAP but isn’t there today.  It could also be included in
> DPP in the configuration frame.

Yes, so eduroam is an explicit configuration (the end user picks it, and
tells their laptop to use it, Yes they could tell it prefer it, which turns
into a kind of auto-magic selection).  Eduroam is a bit unusual at present.

Consider the case of a device (an expensive 3D virtual reality projector with
a wifi interface, let's say) which if onboarded onto ESSID:
Enterprise.Example.com using BRSKI-TEAP. It then expects to use *TEAP* to
authenticate, and the projector could be carried around the building, and
maybe even travels sometimes to other buildings.  Either on an ad-hoc basis,
or because devices are reassigned.   During that period, it needs to refresh
it's Enterprise-WPA certificate, i.e. it's LDevID, and it just uses EST.

One day, you take it to a show to use in the booth.  At this point, you need
to get it to onboard to the show WiFi.   How does that work?

 What is that error, and is it recognizeable?  Do we need a new error
 code to distinguish from "I reject you" from "I reject you but, you
 could try enrolling with BRSKI-TEAP"
>>
>>> I think that can already be detected in the draft based on the action
>>> request frames.
>>
>> To clear, it would be doing TEAP (or EAP-TLS) to connect to the network,
>> because it is already enrolled.   If there are BRSKI-specific responses
>> defined in TEAP, then I'm surprised.

> That is what draft-lear-eap-teap-brski is really about.

well, that assumes that EAP-TEAP is used.
Few enterprises use EAP-TEAP today, so how does EAP-TLS (WPA-Enterprise) tell
the device that it needs to enroll?

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





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


Re: [Emu] BRSKI-TEAP vs regular connection (was Re: EAP questions ...)

2020-01-15 Thread Eliot Lear (elear)


> On 15 Jan 2020, at 16:10, Michael Richardson  wrote:
> 
> 
> Eliot Lear (elear)  wrote:
>>> Owen, do we have a need to recognize that a device needs to perform
>>> onboarding again after a movement?
>>> 
>>> i.e. device A enrolls on network 1, gets an LDevID usable on network
>>> 1, uses that with EAP-FOOBAR.
>>> 
>>> device A then is moved to network 2, it tries to use same LDevID,
>>> receives an error and then recognizes that it needs to perform another
>>> enrollment.
> 
>> I think that is up to the device manufacturer and relates to a number
>> of factors, such as whether the device is mobile, whether it has a
>> reset button, the nature of the device, privacy considerations, whether
>> there are federated capabilities on the device, etc.
> 
> I can see that some of these are important to the device.
> The device may have reasons why it would like to enroll again, but I think
> the question is more about when the network recognizes that it does not need
> to enroll again.
> An example would be a device which was originally enrolled with BRSKI-TEAP,
> but is then provided with roaming credentials (EDU-ROAM).
> 
> How would it know it was on network 2?

Ah.  I misread your note the first time.  The example of 2 is precisely 
eduroam, and this becomes a matter of configuration.  We were talking about 
this at one point, and there is a need to configure a realm as part of all of 
this.  That is something that could be easily be included in TEAP but isn’t 
there today.  It could also be included in DPP in the configuration frame.


> 
>>> What is that error, and is it recognizeable?  Do we need a new error
>>> code to distinguish from "I reject you" from "I reject you but, you
>>> could try enrolling with BRSKI-TEAP"
> 
>> I think that can already be detected in the draft based on the action
>> request frames.
> 
> To clear, it would be doing TEAP (or EAP-TLS) to connect to the network,
> because it is already enrolled.   If there are BRSKI-specific responses
> defined in TEAP, then I'm surprised.

That is what draft-lear-eap-teap-brski is really about.

Eliot

> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-

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


Re: [Emu] BRSKI-TEAP vs regular connection (was Re: EAP questions ...)

2020-01-15 Thread Michael Richardson

Eliot Lear (elear)  wrote:
>> Owen, do we have a need to recognize that a device needs to perform
>> onboarding again after a movement?
>>
>> i.e. device A enrolls on network 1, gets an LDevID usable on network
>> 1, uses that with EAP-FOOBAR.
>>
>> device A then is moved to network 2, it tries to use same LDevID,
>> receives an error and then recognizes that it needs to perform another
>> enrollment.

> I think that is up to the device manufacturer and relates to a number
> of factors, such as whether the device is mobile, whether it has a
> reset button, the nature of the device, privacy considerations, whether
> there are federated capabilities on the device, etc.

I can see that some of these are important to the device.
The device may have reasons why it would like to enroll again, but I think
the question is more about when the network recognizes that it does not need
to enroll again.
An example would be a device which was originally enrolled with BRSKI-TEAP,
but is then provided with roaming credentials (EDU-ROAM).

How would it know it was on network 2?

>> What is that error, and is it recognizeable?  Do we need a new error
>> code to distinguish from "I reject you" from "I reject you but, you
>> could try enrolling with BRSKI-TEAP"

> I think that can already be detected in the draft based on the action
> request frames.

To clear, it would be doing TEAP (or EAP-TLS) to connect to the network,
because it is already enrolled.   If there are BRSKI-specific responses
defined in TEAP, then I'm surprised.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-


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


Re: [Emu] BRSKI-TEAP vs regular connection (was Re: EAP questions ...)

2020-01-15 Thread Eliot Lear (elear)
Hi Michael,


> 
> Owen, do we have a need to recognize that a device needs to perform
> onboarding again after a movement?
> 
> i.e. device A enrolls on network 1, gets an LDevID usable on network 1,
> uses that with EAP-FOOBAR.
> 
> device A then is moved to network 2, it tries to use same LDevID,
> receives an error and then recognizes that it needs to perform another
> enrollment.
> 

I think that is up to the device manufacturer and relates to a number of 
factors, such as whether the device is mobile, whether it has a reset button, 
the nature of the device, privacy considerations, whether there are federated 
capabilities on the device, etc.


> What is that error, and is it recognizeable?  Do we need a new error
> code to distinguish from "I reject you" from "I reject you but, you
> could try enrolling with BRSKI-TEAP"

I think that can already be detected in the draft based on the action request 
frames.

Eliot
> 
> 
> (hoping re-installed laptop works)
> 
> 
> ___
> 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


[Emu] BRSKI-TEAP vs regular connection (was Re: EAP questions ...)

2019-11-07 Thread Michael Richardson

On 2019-11-07 12:43 p.m., Alan DeKok wrote:
>> E.g. we have documented in 
>> https://tools.ietf.org/html/draft-lear-eap-teap-brski-05#section-5 that:
>>
>> "   A device that has not been bootstrapped at all SHOULD send an
>>   identity of teap-bootstrap@TBD1. "
>>
>> If we register that "teap-bootstrap@TBD1" with IANA, then it could be the 
>> mechanism by which the peer tells the server that it wants to use TEAP. If 
>> the server does not support TEAP, it will return an error response.
>   The discussion prior to IETF 105 was that we should use the ".arpa" domain: 
>  https://www.iana.org/domains/arpa  That domain is explicitly intended for 
> this kind of negotiation.  


BTW, related to BRSKI is that the 6tisch CoJP protocol uses 6tisch.arpa
in the CoAP header.

(Not that we'd use the same one, but registering it wasn't hard)

i.e. an EAP Failure message.
>> EAP provides no mechanism to return an error code to the peer. How could we 
>> signal in EAP the error difference between routing vs EAP method unsupported 
>> failures? Or can we at all?
>   EAP provides for a NAK for negotiation, and a Notification packet for 
> signalling errors or messages. Unfortunately, most supplicants don't support 
> Notification.  And the ones that do won't show Notification messages to the 
> end user.

Owen, do we have a need to recognize that a device needs to perform
onboarding again after a movement?

i.e. device A enrolls on network 1, gets an LDevID usable on network 1,
uses that with EAP-FOOBAR.

device A then is moved to network 2, it tries to use same LDevID,
receives an error and then recognizes that it needs to perform another
enrollment.

What is that error, and is it recognizeable?  Do we need a new error
code to distinguish from "I reject you" from "I reject you but, you
could try enrolling with BRSKI-TEAP"


(hoping re-installed laptop works)




pEpkey.asc
Description: application/pgp-keys
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu