Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

2021-06-29 Thread Michael Richardson

Alan DeKok  wrote:
> On Jun 28, 2021, at 8:50 PM, Michael Richardson  
wrote:
>> To date, Enterprises with laptops and PCs have provisioned the IDevID 
into
>> the TPM, themselves, at the same time the device is wiped and the golden
>> image is installed.  So, the TPM identity is actually known to them by 
construction.

> And... if I have my own phone?  Or if a university wishes to tie
> devices to student accounts?  So that they can limit (somewhat) abuses?

> For now, the answer is "too bad".  Or maybe "buy a  MDM solution".

I think that today, the answer is probably too bad because too complex.
But, I think that most phones can do "Enterprise" WPA, and so a certificate
can be loaded in to do EAP-TLS.

> As someone who bought my own phone, I'm not going install some MDM
> solution which lets my employer wipe my personal device.  I would much
> prefer to be able to prove (a) it's my device, and (b) it has a unique
> device identifier.  The simpler the method, the better.

If I were a student, I would also not allow a university (or employer) MDM
solution onto my phone, and I'm not actually sure that it directly helps; it
just makes loading that certificate easier.

--
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] Question for draft-ietf-emu-tls-eap-types-03

2021-06-28 Thread Michael Richardson

Alan DeKok  wrote:
>> If a strong hardware-bound identifier is required, the organization
>> should use the TPM/SE for private key generation during
>> provisioning/onboarding.

> From my reading of TCG / TPM / etc. stuff, the private key describes a
> *particular* device.  Not a *known* device.  i.e. the key is tied to a
> device, so it's a unique token. But it's not an *identifying* token, in
> that the administrator can tell which device is being provisioned.

> There still needs to be a way for the administrator to know which
> device is being used.  Identifying a particular device is done via
> physical examination in a secure network, or via some unique hardware
> identifier.  I might be missing something from the whole TPM
> infrastructure, tho.

To date, Enterprises with laptops and PCs have provisioned the IDevID into
the TPM, themselves, at the same time the device is wiped and the golden
image is installed.  So, the TPM identity is actually known to them by 
construction.

Smartphones do not get provisioned that way, but at the factory.
Ditto IoT devices, and routers that have IDevID.
RFC8995(BRSKI) can help, and Eliot has a proposal about how to run that over 
TEAP.
There are other ways too, and most wind up with an LDevID deployed.

MAC address randomization makes use of EAP-TLS methods that have unique
IDevID as their client identifier much easier than WPA-PSK, where get
nothing.   I expect that is where things will go, but at this point, the
major new "home" mechanism (CHIP/MATTER), seems stuck at sending WPA-PSKs
out, despite actually having a mechanism to deploy LDevIDs to devices.

As many of you know, TLS1.3 is a major win because the client certificate is
not transmitted in the clear during the handshake.  If the supplicant can
validate the server certificate, then a Mallory-in-the-Middle (onpath) attack
also does not get the identity.

--
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] Issue 47 Certificate identity checks

2021-04-13 Thread Michael Richardson

Alan DeKok  wrote:
> One of my colleagues, Arran Cudbard-Bell wrote a cute tool a few years
> ago.  It would pretend to be a WiFI hotspot.  Then when systems tried
> to do EAP, it would strip the realm from the EAP identity.  It would
> then, use HTTPS to connect to a web server for that realm, and download
> that HTTPS server cert.  That cert would then be cloned under a new
> "self signed" CA, and the cloned cert presented to the user.

Why did you need the HTTPS server cert?
Did you need the OIDs, and stuff out of it?  Why wasn't the realm name enough
to make the imposter cert from the non-authorized CA?

I'm just trying to understand how the HTTPS cert is involved here.

--
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] Consensus call for result indicators in EAP-TLS 1.3

2021-02-06 Thread Michael Richardson

Joseph Salowey  wrote:
> There is growing support for mandating result indicators for EAP-TLS
> 1.3.  The result indicators help protect the EAP protocol exchange in
> the many different types of environments EAP-TLS is used and make the
> integration with the EAP state machine clearer.  This has the impact of
> adding a round trip to EAP-TLS 1.3 making a total of 4.5 round trips.
> It may be possible to optimize this exchange, but that would need
> further study and would be beyond the scope of this effort.

> This consensus call has two parts:

> 1. Please respond to the list if you support adding explicit result
> indications of success and failure from the EAP Server to the EAP Peer
> in EAP-TLS 1.3.  If you object please respond to the list indicating
> why.

I support this.

> 2. Please respond to the list if you support using TLS close_notify
> alert for a success indication and TLS error alert for a failure
> indication.  If you object please respond to the list indicating why.

As I understand it, it is the use of Close_Notify that pushes us to 4.5 round
trips.

Given a client-certificate (or chain) of >1500 bytes more than one packet would 
be
required send that, and I believe that we can't send Close_Notify until the
certificate has been communicated (and verified).

So my question is: is this really 3.5 round trips -> 4.5 round trips, or is
it really more like that we are going from perhaps 5.5 round trips to 6.5
round trips (for example).
I posit this, because I think that the increase in round trip count is
largely irrelevant on non-challenged (RFC7228 term) networks.

--
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] Underspecification of EAP-TLS 1.3 State Machine

2021-02-03 Thread Michael Richardson

I haven't been able to follow all of thread on the impedance mismatch between
EAP and TLS, which the EAP-TLS specification is intended to resolve.
(I did talk on the phone with Alan yesterday, and he recapped some issues for
me.   My other qualification is that I implemented EAP-SIM 20 years ago, and
I did some EAP over IKEv1 work at one point)

My understanding is that:
  1) the TLS Finish message can now occur prior to the client certificate
 even being transmitted, let alone validated.
 This is a feature in TLS 1.3 that lets application data in the
 typical browser->http server occur very early.

  2) As such, it is possible to run the TLS-Exporter function prior to
 actually having authenticated the client.
 This is part of the TLS 1.3 changes that essentially permit either
 end to (re-)authenticate at any point in the protocol.

  3) The EAP-Success message is not authenticated in any way.

So it seems to be that:

a) The EAP-Success is meaningless.  The client needs to process it, but
   it should not affect the state machine at all!

b) Success means being able to use the derived keys.
   The keys won't be installed by the AAA server into the authenticator
   until it has performed appropriate validation of the client.
   (e.g, received and validated the client certificate)

c) More important than EAP-Success, is legitimate failure.   They need to be
   unforgeable by an attacker.   Success is easy to determine, and
   progress is easy to move forward with.  What breaks forward motion are
   failure messages.  They need to be properly authenticated.

While EAP-TLS does not really do anything with the resulting TLS channel
afterwards, there are some protocols like EAP-TEAP (and BRSKI-TEAP), that
would like to use the channel afterwards.  So anything learnt in EAP-TLS 1.3
will get repeated.

My instinct is that the best thing would be to have a TLS-level message which
EAP-TLS 1.3 should define.  This is the real success or failure message.  TLS
libraries would have to cope.

The application data, byte, vs zero-length data discussion seems to be
basically dancing around this.  TLS 1.3 is too flexible, and we can't either
constrain the TLS 1.3 state machine, nor can we depend upon it anymore the
way that one could with 1.2.

--
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] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-05 Thread Michael Richardson

pedantically, because I think that there is much confusion here.
Let me go back to the whole sentence:

Alan>  Therefore, we need an explicit signal to the EAP-TLS layer that the
Alan>  EAP-TLS method has finished.  Discussion on the list went back and
Alan>  forth between CloseNotify and sending one octet of application data.
Alan>  Implementations have done both.  The conclusion was that the one octet
Alan>  of application data was slightly easier to implement.

Alan DeKok  wrote:
>> Alan DeKok  wrote:
>>> Therefore, we need an explicit signal to the EAP-TLS layer that the
>>
>> Do you mean, "to the EAP layer"?
>> s/EAP-TLS layer/EAP/ ??

> If the EAP-TLS layer allows TLS negotiation OR EAP-Success, then it's
> possible to bypass TLS by spoofing an EAP-Success.  So the EAP-TLS
> layer needs to have a way to say "we're done, EAP-Success is now OK".

> It's really nested:  EAP ( EAP-TLS ( TLS ) )

Okay, so I think that we need:
  1) signal from the TLS layer to EAP-TLS layer
  2) signal from the EAP-TLS layer to the EAP layer

But, you said, above:

 "to the EAP-TLS layer that the EAP-TLS method has finished"

so I still think that there might be a typo :-)

--
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] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-05 Thread Michael Richardson

Alan DeKok  wrote:
> Therefore, we need an explicit signal to the EAP-TLS layer that the

Do you mean, "to the EAP layer"?
s/EAP-TLS layer/EAP/ ??

> EAP-TLS method has finished.


--
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] [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

2020-12-09 Thread Michael Richardson

Dan Garcia  wrote:
> EAP can be used in the context of IoT for authentication.

But, to what end?

1) If it is onboarding a new device, then there is no connectivity until after 
authentication.
   so you can't use CoAP, you have to use 802.1x, or some equivalent, or
   create a system such as draft-ietf-6tisch-minimal-security.
   Which does use CoAP and OSCORE already.

2) If it for application authentication, then you need to use EAP to setup
   MSK for later use by a context.
   We do this in IKEv2, (D)TLS already.

So the only left would be OSCORE, yet you write "could", as if it was an 
afterthought.

Tell me what is your application?  What will be impossible if we don't do
this work?

--
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] [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

2020-12-07 Thread Michael Richardson

Could someone point to a use case for "EAP over CoAP" please?
Is the goal to key an OSCORE context, or what?

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



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


Re: [Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

2020-11-02 Thread Michael Richardson

Eliot Lear  wrote:
> Consider the scenario when you have the CA sitting off somewhere in the
> distance, and a power failure or other service interruption has
> occurred.  Should the client refuse to come up because stapling didn’t
> happen?  Should old stapling information be retained, and what does
> that mean in the context of the nonce extension?  I had thought we said
> that this risk is mitigated by the choice of the deployment to include
> the OCSP extension information in the cert- or not.  At that point the
> deployment can make the decision.

Eliot,

1) it seems that if the CA hasn't put stapling information in, then it won't be 
needed.

2) if you still want stapling, then it seems to me that there are lifetimes in 
the
   staple which can be adjusted to deal with anticipated service
   interruptions in connectivity to the CA.


--
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] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

2020-10-30 Thread Michael Richardson

Joseph Salowey  wrote:
> On Fri, Oct 30, 2020 at 4:44 AM Michael Richardson 
> wrote:

>>
>> Joseph Salowey  wrote:
>> >> I suggest:
>> >>
>> >> “EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate
>> >> recovation checks,  MUST implement Certificate Status Requests
>> using OCSP
>> >> stapling as specified in Section 4.4.2.1 of [RFC8446].
>>
>> > [Joe] Thanks Michael,  I think your suggestion is a better way to
>> phrase it
>>
>> Just so that we are clear:  this mandates OCSP+stapling for systems that 
do
>> revocation checks.
>>
>> Systems that don't do revocation checks (current mbedtls), therefore 
don't
>> need to do OCSP or stapling.
>>

> [Joe] That's not how I read your text.  I think your text mandates
> OCSP+stapling for systems that use OCSP for revocation.

> TLS 1.3 RFC 8446 does not mandate a particular revocation mechanism 
either,
> as revocation is part of PKIX.

I thought that someone said that it did.
In which case, we are under no additional compulsion to support revocation
than we were before.

Hannes and Eliot have brought up significant operational challenges in
supporting OCSP in some environments.  I think that it should be a local 
decision.

> Also to be clear you text does not mandate that either servers or clients
> support OCSP Stapling.

> I think it would be appropriate to modify your text to replace "use" with
> support.

> "EAP-TLS servers supporting TLS 1.3 that support OCSP to do certificate
> revocation checks,  MUST implement Certificate Status Requests using OCSP
> stapling as specified in Section 4.4.2.1 of [RFC8446]."

okay.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[






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

> 
> Alternatives:

> 

--
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] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

2020-10-30 Thread Michael Richardson

Joseph Salowey  wrote:
>> I suggest:
>>
>> “EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate
>> recovation checks,  MUST implement Certificate Status Requests using OCSP
>> stapling as specified in Section 4.4.2.1 of [RFC8446].

> [Joe] Thanks Michael,  I think your suggestion is a better way to phrase 
it

Just so that we are clear:  this mandates OCSP+stapling for systems that do
revocation checks.

Systems that don't do revocation checks (current mbedtls), therefore don't
need to do OCSP or stapling.

--
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] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

2020-10-29 Thread Michael Richardson

Joseph Salowey  wrote:
> 2. Require Servers to Implement and Recommended to Use OCSP with text
> similar to the following:

I don't think that this text is quite right.

I note that "RECOMMENDED" is a synonym for SHOULD, and usually we ask
documents to explain what a reasonable exception might look like.
This text does not do that.

> “EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
> Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446].  It
> is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for
> verifying the status of server certificates as specified in Section 
4.4.2.1
> of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate
> status of the EAP-TLS server, it MUST use Certificate Status Requests for
> the server's certificate chain and it MUST treat a CertificateEntry 
(except
> the trust anchor) without a valid CertificateStatus extension as invalid
> and abort the handshake with an appropriate alert.“

I suggest:

“EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate
recovation checks,  MUST implement Certificate Status Requests using OCSP
stapling as specified in Section 4.4.2.1 of [RFC8446].

It is RECOMMENDED that EAP-TLS peers and servers use OCSP (with stapling) for
verifying the status of server certificates as specified in Section 4.4.2.1
of [RFC8446].


When an EAP-TLS peer uses OCSP to verify the certificate status of the
EAP-TLS server, it MUST use Certificate Status Requests for the server's
certificate chain and it MUST treat a CertificateEntry (except the trust
anchor) without a valid CertificateStatus extension as invalid and abort the
handshake with an appropriate alert.“

I don't know much about the last part.
I suggest it be split as three paragraphs for readability.

--
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] draft-ietf-emu-eap-tls13-11: OCSP Stapling

2020-10-26 Thread Michael Richardson

Russ Housley  wrote:
>>> The second is, I think, that the EAP server (Authentication Server), 
would run
>>> an OCSP responder locally so that it can mint it's own staples.
>>> AFAIK, each certificate can point to a different OCSP signer.
>>
>> Does anyone actually do that?

> I am aware of some places that generate an OCSP response for the entire
> population of certificates, and those responsed are distributed to many
> locations.  I am not aware of anyone that distributes the OCSP
> responder signature private key to multiple locations.

Does anyone put different OCSP signers into different certificates?
I.e. shard the work?

I think that splitting the OCSP reponses to many locations might solve the
industrial situation well.
I think that there is also some significant space to tune the validity
periods.

But, I agree with Eliot: the OCSP responder is new.

It seems that maybe SHOULD would appropriate on OCSP.

--
]   Never tell me the odds!     | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



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


Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

2020-10-26 Thread Michael Richardson

Eliot Lear  wrote:
>> No.  There are several steps before we get to raw public keys.
>>
>> The first is that the duration of the Staples could be lengthed to 
accomodate
>> anticipated down time for the (now) critical OCSP responder.
>> A second part is that perhaps staples could be provisioned in advance 
for the
>> server to cover for planned maintenance periods.  I don't imagine this 
is in
>> any protocol, but could be added.

> But to what end?  We don’t even know if these devices can reasonably
> deal with any secure notion of time.  Even checking cert expiry is a
> bit questionable in some cases, especially if the cert has been seen
> before, and the device is of someone critical value.  And it’s not
> clear what the value is with a lengthy expiry.

okay, but this is clearly a problem regardless.
Devices without known good time can't do very many useful things, and
probably just could ignore the staple.
But, laptops and mobiles do have good time, and they can do the right thing.

>> The second is, I think, that the EAP server (Authentication Server), 
would run
>> an OCSP responder locally so that it can mint it's own staples.
>> AFAIK, each certificate can point to a different OCSP signer.

> Does anyone actually do that?

I dunno, but it is possible as far as I can tell.

>> While this degenerate case of Authentication Server + OCSP Signer on the 
same
>> machine is kinda dumb from a overall security point of view, it's still
>> better than raw public keys.

> Yes.  Let’s think about who OCSP is protecting in this case.  It’s
> protecting the client from the Authentication Server, in theory.

Yes, from compromises of the Authentication Server via loss of control of 
private key.

>> If the OCSP signer is moved to some TPM then
>> there is a win.  Not all TPMs can provide the performance required to 
handle
>> the server certificate, but resigning an OCSP Staple once every ten 
minutes
>> or something shouldn't be a problem.

> If this is the case, then a public key could be moved into the the TPM 
just as easily.

If the TPM can accomodate thousands of signatures per minute, which fTPMs
probably can accomodate (same CPU, just different context), then sure.
Many older, i2c interfaced physical-TPMs do not accomodate that rate.

>> The third is, I think, that the EAP server runs an entirely 
self-contained
>> private CA.  The OCSP responder is now clearly an integral part of the 
local
>> system.

> Again, what threat are we protecting against?

The self-contained CA might have a passphrase, so there is some accomodation
updating the signing key for new algorithms, etc.  while the trust anchor
which is distributed is appropriate pessimistic.

--
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] draft-ietf-emu-eap-tls13-11: OCSP Stapling

2020-10-26 Thread Michael Richardson

Eliot Lear  wrote:
>> The EAP server is expected to frequently request a OCSP response from
>>the OCSP responder (a server typically run by the certificate
>>issuer). The OCSP response is then added to the Servers Certificate
>>message as long as it is valid. Before the OCSP response is close to
>>expiring, the EAP server requests a new OCSP response from the OCSP
>>responder.

> Right.  What this is saying is that a local deployment MUST run an OCSP
> responder.  If that OCSP responder is unavailable, then what?  Now
> imagine we are discussing critical infrastructure where the responder
> is not in the same room, and there are network connectivity problems.
> The device joining the network needs local access and that is it.  Does
> that mean it should not use EAP-TLS?  Or are we saying that they MUST
> use naked public keys?

No.  There are several steps before we get to raw public keys.

The first is that the duration of the Staples could be lengthed to accomodate
anticipated down time for the (now) critical OCSP responder.
A second part is that perhaps staples could be provisioned in advance for the
server to cover for planned maintenance periods.  I don't imagine this is in
any protocol, but could be added.

The second is, I think, that the EAP server (Authentication Server), would run
an OCSP responder locally so that it can mint it's own staples.
AFAIK, each certificate can point to a different OCSP signer.
While this degenerate case of Authentication Server + OCSP Signer on the same
machine is kinda dumb from a overall security point of view, it's still
better than raw public keys.  If the OCSP signer is moved to some TPM then
there is a win.  Not all TPMs can provide the performance required to handle
the server certificate, but resigning an OCSP Staple once every ten minutes
or something shouldn't be a problem.

The third is, I think, that the EAP server runs an entirely self-contained
private CA.  The OCSP responder is now clearly an integral part of the local
system.

Do we need to write an Operational Considerations document here?

> For many devices the manufacturers will be unable to predict whether a
> device will or will not have direct access to anything.  It specific to
> deployment circumstances.  Also, running an OCSP server is something
> that will be very new for many enterprises.


--
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] draft-ietf-emu-eap-tls13-11: OCSP Stapling

2020-10-26 Thread Michael Richardson

John Mattsson  wrote:
> 1. Basically all TLS implementations support OSCP, and a majority
> support OSCP stapling (Certificate Status Request). Mbed is an
> exception rather than the rule.

Is this for server and client certificates, or just server certificates?
It seems that getting the client certificate staple would be difficult for
offline clients :-)

> https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

Also, consider that an mbedtls EAP client could just not process the OCSP+Staple
for now.  That would be non-compliant, but it would work.
(The opposite for the server is not the case)

> 3. NIST SP 800-52 Rev 2 mandates that the server shall support use of
> the Certificate Status Request extension (i.e. OCSP stapling).

> - I do not think there is any wiggle room at all in the current version 
of the draft:

> "When EAP-TLS is used with TLS 1.3, the peer and server MUST use 
Certificate Status Requests [RFC6066]
> for the server's certificate chain"

> Note that in the current draft it is unspecified how the server checks
> the revocation status of the client's certificate:

> "When EAP-TLS is used with TLS 1.3, the server MUST check the
> revocation status of the certificates in the client's certificate chain."

So, OCSP would comply work, but insisting on stapling would be dumb.

> - My view is that OSCP stapling is a very good fit for EAP in
> particular and is well-supported enough to be mandated. Mandating
> stapling for EAP-TLS 1.3 from the start avoids having to rely on the
> X.509 must-staple extension. Any implementation not supporting OCSP
> stapling should implement it together with TLS 1.3. I do not think the
> requirent should be softened, but if it is, my view is that is should
> be softened as little as possible.

--
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] draft-ietf-emu-eap-tls13-11: OCSP Stapling

2020-10-22 Thread Michael Richardson

Joseph Salowey  wrote:
> On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear 

> wrote:

>> +1.  How does anyone even do OCSP without having first gotten onto the
>> network?

> [Joe] THat is what OCSP stapling is supposed to solve since the OCSP
> messages are sent in the TLS handshake.   I believe there are some EAP-TLS
> implementations that support OCSP, but I am not sure if it is actually
> deployed.

I think that it should say, if you do OCSP, then you must staple.
But, the intro suggests that revocation checking is mandatory with TLS 1.3.
(I didn't double check if that's MUST, SHOULD, or what)

Since CRLs won't be fresh and can't be retrieved until online, then it seems
that OCSP is needed if one is going to revocation checking.

What I read in section 5.4 is that servers have to support OCSP stapling
requests.  I see a tiny bit of wiggle room as to whether the peer actually
must USE it :-)
Maybe that wiggle room can be made official for Hannes.

The document currently says: (1.0)

   Privacy is mandatory and achieved without any additional round-trips,
   revocation checking is mandatory and simplified with OCSP stapling,

and:

5.4.  Certificate Revocation

   This section updates Section 5.4 of [RFC5216].

   While certificates may have long validity periods, there are a number
   of reasons (e.g. key compromise, CA compromise, privilege withdrawn,
   etc.) why client, server, or sub-CA certificates have to be revoked
   before their expiry date.  Revocation of the EAP server's certificate
   is complicated by the fact that the EAP peer may not have Internet
   connectivity until authentication completes.

   EAP-TLS peers and servers supporting TLS 1.3 MUST support Certificate
   Status Requests (OCSP stapling) as specified in [RFC6066] and
   Section 4.4.2.1 of [RFC8446].  When EAP-TLS is used with TLS 1.3, the
   peer and server MUST use Certificate Status Requests [RFC6066] for
   the server's certificate chain and the EAP peer MUST treat a
   CertificateEntry (except the trust anchor) without a valid
   CertificateStatus extension as invalid and abort the handshake with
   an appropriate alert.  When EAP-TLS is used with TLS 1.3, the server
   MUST check the revocation status of the certificates in the client's
   certificate chain.

   The OCSP status handling in TLS 1.3 is different from earlier
   versions of TLS, see Section 4.4.2.1 of [RFC8446].  In TLS 1.3 the
   OCSP information is carried in the CertificateEntry containing the
   associated certificate instead of a separate CertificateStatus
   message as in [RFC4366].  This enables sending OCSP information for
   all certificates in the certificate chain.


>> Eliot
>>
>> On 21 Oct 2020, at 11:02, Hannes Tschofenig 
>> wrote:
>>
>> Hi all,
>>
>> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and 
I
>> believe this is a problem for implementations. This extra burden is IMHO
>> unjustified. For the type of deployments where EAP is used there is no 
need
>> for a mandatory certificate revocation checking with OCSP.
>>
>> Having it optional, like the use of many other TLS extensions, is fine 
for
>> me. FWIW even TLS 1.3, which is used in a more generic environment, does
>> not mandate the use of OCSP stapling.
>>
>> This requirement will make the problem described in
>> draft-ietf-emu-eaptlscert worse. I am sure the authors are aware of this
>> fact since they are also co-authors of draft-ietf-emu-eaptlscert.
>>
>> Ciao
>> Hannes
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy 
the
>> information in any medium. Thank you.
>> ___
>> 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
>>

> --------
> Alternatives:

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

--
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] draft-ietf-emu-eap-tls13-11: OCSP Stapling

2020-10-22 Thread Michael Richardson

Hannes Tschofenig  wrote:
> Thanks for the question. I am objecting to the mandatory use of OCSP for 
TLS 1.3 in EAP-TLS.
> I am fine with having it optional.

okay, so it's not about the stapling, at all for you, it's about the OCSP 
itself.

--
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] draft-ietf-emu-eap-tls13-11: OCSP Stapling

2020-10-21 Thread Michael Richardson

Hannes Tschofenig  wrote:
> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS)
> and I believe this is a problem for implementations. This extra burden
> is IMHO unjustified. For the type of deployments where EAP is used
> there is no need for a mandatory certificate revocation checking with
> OCSP.

Is it:
   1) there is no need for mandatory certificate revocation checking
   2) there is no need to make OCSP checking the mandatory method for 
certificate revocation checking

Are you objecting to:
   a) mandatory certificate revocation checking
   b) mandatory OCSP
   c) mandatory OCSP *stapling* when using OCSP

I think, if you the client (who has no Internet yet), is going to be able to
do certificate revocation checking, then doing it via OCSP stapling is the
right way to go.  It can't do ONLINE CSP, because it has no Internet.

> Having it optional, like the use of many other TLS extensions, is fine
> for me. FWIW even TLS 1.3, which is used in a more generic environment,
> does not mandate the use of OCSP stapling.

> This requirement will make the problem described in
> draft-ietf-emu-eaptlscert worse. I am sure the authors are aware of
> this fact since they are also co-authors of draft-ietf-emu-eaptlscert.

--
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] [Iot-directorate] Iotdir early review of draft-ietf-emu-eap-noob-01

2020-07-08 Thread Michael Richardson

Speaking as a WG participant.

Dave Thaler via Datatracker  wrote:
> 3) Section 3.3.2 says:
>> The in-band messages are formatted as JSON objects [RFC8259]

> So this limits applicability to constrained IoT devices, since JSON can be
> verbose compared to, say, CBOR, and if the IoT device already uses CBOR 
for
> its normal protocol use this requires adding a separate parser for JSON 
which
> may cause code size issues.   Is there a rationale for why CBOR could not 
be
> an option?  E.g., if this protocol is not applicable for constrained 
devices,
> then say so.  (I don’t know whether EAP itself already inherently has
> problems that limit its applicability for constrained devices.)

I think that the document predates widespread availability of CBOR :-)
I think that it would benefit from only using CBOR, as CBOR works into EAP
much better than I think JSON does.
That would be a radical change, but the document as only just been adopted by
the EMU WG.

To the extent that EAP is used more on 802.11 rather than 802.15.4 [not that
you can't do EAP/1x on 15.4, it just hasn't caught on], IoT devices that have
power budget for WiFi can generally do EAP.  There is a large variety of
arduino class devices running FreeRTOS+micropython, for instance, which
already have EAP supplicants.

CBOR would be easier for them in the C code parts of them, while if the
EAP-NOOB were to involve the python code (for callbacks, etc.) it wouldn't
matter much as whether JSON or CBOR, it would likely be presented as python
dict() anyway.

Where there is a problem is a slightly smaller class of device which use
various WiFi *MODULES*.  Usually the microcontroller speaks i2c to this
module, and the module takes care of all the TCP/IP/Ethernet/WiFi stuff.
Those devices do not use EAP today, and they are hard to upgrade.
(and from a security point of view, those architectures concern me greatly)

--
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] Secdir early review of draft-ietf-emu-eap-noob-01

2020-06-28 Thread Michael Richardson

Steve Hanna via Datatracker  wrote:
> Reviewer: Steve Hanna
> Review result: Not Ready

Steve thanks for the great review!
I wanted to respond as an IoT onboarding expert and EMU WG member.

> * Bootstrapping an IoT device involves many tasks that extend far beyond 
what
> is accomplished by EAP-NOOB: configuring the services that the device
> can/should employ within its new context (including how to reach and

Hi, so your comments are well taken, but it's really an unreasonably high
standard.  While it is really important to get the configuration mechanisms
in place, they are even more diverse than onboarding.
That's an entire ocean of disagreement here.
I would certainly love to get a handle on this.
When it comes to standardization, really have to be very selective on how big
a thing to bite off.  I think that we can incrementally get to this, but
first we need some success with getting even one onboarding spec working.

So I don't think it's reasonable to evaluate EAP-NOOB (or BRSKI-TEEP) by this 
critiera.

> * IoT device provisioning is not a new problem. In fact, it has been 
solved
> hundreds of times. Most of those solutions are proprietary but some 
standards
> efforts are ongoing now: IoTopia, FIDO IoT, Connected Home over IP, 
IP-BLiS,
> etc. Why ignore these? Why not reach out and try to help them?

Well, of those groups, many of them are completely pay-to-play fora, and do
all of their work behind closed doors. In many cases, they look to the IETF
for components, such as EAP-NOOB, BRSKI, etc. that they can incorporate into
their designs.  Some are actively hostile towards an an actual written
standard, preferring that everyone license a particular software stack instead.
I think that EAP-NOOB has benefited greatly from academic and industrial review.

> * This proposal assumes that the IoT device has a user interface (camera,
> screen, etc.). What about those that don’t?

Yup. Some don't, and you need to do something else.
But, a lot of devices *do* have displays.
Think about any industrial or hospital instrument.
They all go "ping", and have a cool display to put a graph on :-)

> * Won’t this protocol apply to a relatively small subset of the networks 
that
> IoT devices will need to connect to? Few IoT networks run EAP.

EAP is very popular in industrial and enterprise situations.
EAP can be easily introduced into home network, with the Authentication
Server running locally.  Many have done this, and it is supported in Openwrt 
today.

> * How will the device know which network to connect to, in the first
> place?

This is a good question, and I can offer no answer for the EAP-NOOB case, and
I leave it to the authors to respond to your other comments.

--
]   Never tell me the odds!     | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[


--
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] TEAP Request-Action TLV

2020-04-30 Thread Michael Richardson

Eliot Lear  wrote:
> Here is a circumstance one could easily imagine, and in fact we
> attempted to address in draft-lear-eap-teap-brski:

> Client requires a new certificate for some reason or another.  Perhaps
> its is about to expire, or perhaps the signer has been compromised, or
> what have you.

I think that's a really bad example.  I can talk about the reasons, but I
think it would detract from your query.
Maybe you can give me a different use case?

> We were thinking that we could use the Request-Action Frame for this
> purpose with a type of PKCS#10.  But that now seems wrong, as the
> language in the draft states that one appends a Request-Action frame
> with a full TLV, and not just a type,  and further that the other end
> process the TLV.  In looking at Jouni’s code, he is doing precisely
> that with the PAC TLV.

> And so it seems we have three choices:

> Create a new TLV that has a length of two that can be used in a 
REQUEST_ACTION frame.
> Create a new TLV that is what we thought we meant: here is a list of
> two(ish)-byte types whose TLVs I want you to send to me.

> Hard code the ordering of requests so everyone knows what to expect.

--
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] I-D Action: draft-ietf-emu-eaptlscert-02.txt

2020-03-16 Thread Michael Richardson

Hi, I didn't know about this document, and I've just read it.

Some questions:

1) "RADIUS can generally transport only about 4000 octets of EAP in a single
   message."

   Can you explain this?  Radius over UDP would have fragment a 4000 octet
   message, so why is the number 4000?  That's three fragments.  Is the
   loss amount beyond this too high?  Or is it that common implementations
   just don't support larger sizes?

   RFC6613 radius over TCP would not seem to have that limitation, but
   I won't be surprised if it is less common. I've certainly used it
   as it solves the the NAT and Radius key problem. (Alan?)

2) the problem appears is documented to occur at 60Kbyte chain size.
   With 6 intermediate certificates in the chain, that provides for
   10KByte for each certificate, which seems rather generous to me.
   I am not objecting to solving the problem as stated, but I want to
   understand what the goals really are.

   The advice in section 4.1 is good.  Are full postal addresses in
   intermediate CAs really the culprit here?

3) section 4.2.2, about caching certificates from a previous TLS session
   is interesting.  I'm unfamiliar with rfc7924, does it use a session
   resumption ticket, or will any previous connection do?
   (It seems that a session resumption process is not required?)
   This might provide motivation Alan's question about why/how one
   might resume an HTTPS TLS session over EAP-TLS.

I was surprised to get to the end of the document without any suggestions
about sending certificates by reference rather than value.
This is the method that we have adopted on draft-selander-ace-ake-authz.
We considered using the mathmesh UDF mechanism, but found a way that could
instead send only the location while actually encrypting the ID as a privacy
enhancement.
I don't think such a thing would be desireable, and TLS 1.3 provides other
equivalent privacy enhancements, but I want to suggest you consider a new
certificate container which contains a reference.  IKEv2 already has that.

--
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] [lamps] Using public CA infrastructure for autonomic bootstrapping over EAP.

2020-02-01 Thread Michael Richardson

{did I answer this already?}

Benjamin Kaduk  wrote:
> You mention in a couple places that EAP server certificate should be
> identifying an rfc822Name DN, and I think I'm confused about what you
> mean.  (I suspect I'm seeing "rfc822Name" and jumping to what ACP does,
> which is wrong.)  Could you walk through an example of what that would
> look like to help un-confuse me?

There is no connection to the ACP situation.
I think that the idea is that the ESSID would be set to an FQDN,
and the EAP-TLS server certificate would have the same FQDN in the
rfc822Name.

Given ACME dns-01 type challenge, that would provide evidence that
the entity was authoritative for the name.  In a LE ACME certificate that was
issued via dns-01, I found two policy OIDS: 1.3.6.1.4.1.44947.1.1.1 (unknown)
and 2.23.140.1.2.1 (domain-validated).  I think that domain-validated can
mean http-01 or dns-01, but I don't know.

I don't know if the above mechanism really works.

I don't think that this would matter if the goal was TEAP-BRSKI, because we
can pin an EE certificate from any origin.  Once the voucher is issued, then
the pledge will download a new set of trust anchors, so it doesn't really
matter once the device is enrolled.  

It can then use the new trust anchor with (any) other EAP mechanisms to connect
afterwards.  Critically, if the trust anchor is a public anchor, then the
client needs to pin the rfc822Name as well as the anchor, otherwise any EE
issued by the public trust anchor could be a valid authenticator.

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 





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


[Emu] using public CAs for IDevID and device certificates

2020-01-17 Thread Michael Richardson

Michael Richardson  wrote:
> 3.  End User Client Certificates

> A client certificate used to authenticate an end user may be used for
> mutual authentication in TLS, ***EAP-TLS***, or messaging.  The client

> (to be very very very clear: not a consensus document at this point)
> [See followup message, I don't want to distract this thread too much]

It would also be very nice to be use LetsEncrypt for device certificates,
and draft-moriarty-acme-client speaks to some of this, but given 90-day
LetsEncrypt expiry, that won't fly. (I have running code that deals
with the factory processing)

Having an IDevID on a thing (router, appliance, home router) with a public CA
trust path means that one connect to it from a stock browser/smartphone
without error.
Yes, that implies the thing has a name (the name is in the certificate), and
that the name is resolvable by the browser, at least locally.
That's possible, particularly given IPv6 ULA  RR for home routers,
but also using local DNS mechanisms. (again, I have running code)

It is, sadly, not feasible to buy certificates from a public CA, as the
current CAFORUM 2yr (25 month) limit won't work for most supply chain
logistics.  The CAFORUM has been discussing 13 month limits, with noises
for even shorter terms.  I read the lists for awhile, but I don't know if
13 months went to a vote yet.

Okay, I thought: no problem, just get an Enterprise sub-CA with a
nameconstraint limiting issued certificates. That was a thing at one
point.   Surely, I can then control the expiry dates myself?
There was even a CVE about windows-server not validating the name constrained
correctly a decade ago.

I did persue this anyway about a year ago with a few CAs. Only one of them
actually could spell "Enterprise CA"!! It's just not offered, as a result,
I think of the newer CAFORUM rules.  I am sad, but I understand why it
happened.

yes, Enterprise CAs were in order O($10K-USD),
but spread over 100K+ product instances, that's not a huge cost.

I was offered a hosted sub-CA. If I wanted it to have a public trust
anchor, the price was $450/certificate. (Yes, I got the decimal place
right. I did ask for confirmation here twice. I was expecting $4.50/certificate,
with some minimal commitment, given that it would have a PathNameConstraint).
That's for a 25 month certificate, which I thought, maybe is long enough for
the step after proof-of-concept.

With BRSKI ANIMA/ACP, selling into Operators and Enterprises, using a
private CA for the IDevID is just barely acceptable, as those operators
can just probably configure new trust anchors into the Registrar.  Maybe.
With good enough software.  Maybe we can come up with some additional
mechanism, maybe involving SRV and/or TLSA records.

This probably won't fly into the residential or SOHO space, thus the interest
in either having a public trust anchor for IDevID signing, or... CREATING A
NEW SET OF semi-public CAs.Honestly, this project would be simple
compared to what I've seen of the US Federal cross-CA system :-)

I wrote two documents in December which I'd appreciate feedback on:
1) Operational Considerations for Manufacturer Authorized Signing Authority
   draft-richardson-anima-masa-considerations-01

   This is about the private CA used to sign the IDevID.

2) Operational Considerations for BRSKI Registrar
   draft-richardson-anima-registrar-considerations-01
   This is about the private CA that the operator is expected to run.


--
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] [lamps] EAP/EMU recommendations for client cert validation logic

2020-01-17 Thread Michael Richardson

Ryan Sleevi  wrote:
> While I think people are missing the forest for the tree, here's an
> example CP/CPS from a CA:
> 
https://www.certsign.ro/media/document/ZytpRDNNUTFHR01Ra2MxVUx4REdQZz09/original/CPS%20OV%20SSL_v%201.10_April%202019.pdf

certsign.ro uses a Fortinet.com certificate on their SMTP server.
Does Fortinet.com's CSP permit SMTP usage?
The certificate does not have the serverAuth bit set.

> Customer will only use a TLS/SSL Certificate on the servers
> accessible at the domain names listed in the issued Certificate

> Remind me how an EAP-TLS/RADIUS server is accessible at that domain
> name? And if someone points their domain name to my server, would that
> require revocation?

"accessible" is not defined.  maybe CAFORUM needs to write port 443 from now on?
If you were part of eduroam, and you uses ryan-i...@sleevi.com as your
identity, then the roaming mechanism would connect eventually to your Radius
server using that name.  Thus, it is accessible.

Your gear analogy is understood, but for many of us, we see the specs as
having been designed by lawyers rather than engineers in order to maximize
profit and minimize interoperability.  I'm not arguing we are right.
It just feels like needless and wastefully restrictive attempts to create 
market verticals.

> In the specific context of thinking about "#2" - what a touch-free
> future looks like - having it use the same root store as Web browsers
> is the anti-pattern, because the requirements are different.

And yet, almost every single thing out there would like to be connected to by a 
browser.
They can't, so we have an app-per-thing, and/or no-security.

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


[Emu] Using public CA infrastructure for autonomic bootstrapping over EAP.

2020-01-17 Thread Michael Richardson
 or messaging.  The client

   (to be very very very clear: not a consensus document at this point)
   [See followup message, I don't want to distract this thread too much]

3) If the Registrar (which is probably also the EAP-TLS/EAP-TEAP
   authenticator end-point) has a certificate from a public CA, (and this is
   pinned in an RFC8366 voucher), then there become a few challenges due to a 
desire to:

   a) change / rekeying the public key.
  Pinning the CA+DN rather than the EE cert can solve this, at the cost
  of adding complexity to the pledge.

   b) being able to change from CA X to Y, which means that only the DN can
  be pinned. In effect, the rfc822Name!

   Note that the voucher is typically only evaluated at onboarding time.
   In an online (nonced) process, then that happens mere seconds after the
   voucher is issued, and the changes in (a) and (b) do not matter much.

   During the EST process, the pledge can get trust anchors with which to 
validate
   the Registrar/Authentication-Server.  The specific CA which is currently
   being used can be returned.  It matters little whether it is public or
   private.

   {I personally do not think that running a private CA is that big a deal if
   you are willing to write a hundred lines of code to manage it.  It
   certainly is a pain if you expect the operator to use openssl command line!
   (But, then I'm regularly told that my solutions are too complex for regular 
people)}

   The trust anchor will get used regularly to do EAP/WPA operations from the 
device.
   The ability to validate the certificate is not affected by the (a) change
   above.

   The problem is that as currently described, we do not say to pin the DN.
   So *ANY* name from that CA will be valid for that connection.  In the case
   of public CA, then this means that the client would connect to any network
   that has an EE from the same CA.  That's way too easy to spoof.  Hell, it
   can occur easily by non-malicious actors: just two offices or houses
   within WIFI distance.

   And as described above, there is currently no validation of the DN by
   current clients, nor is there validation of extensions.

   The (b) switch is probably, in my opinion, not tractable easily.
   RFC7030's /cacerts (section 4.1.3) returns the certificates (plural) are
   returned.  If the (b) switch could be coordinated enough in advance to
   permit normal RFC7030 renewals to get the Y trust anchor that could work.

===

So, it seems that we ought to:
  a) suggest that EAP-TLS (and EAP-TEAP) clients should include the DN
 (rfc822Name) of the certificate that they should be talking to.

  b) we should perhaps have an OID extension in the CA certificate (trust
 anchor) that says if the CA will use the id-kp-eapOverLAN bit or not.
 (or other extensions)
 If so, then the client should insist that the resulting extension be 
present.
 Maybe there is another way to do this that would be easier, but this
 makes sense to me.

  c) We may want to Update RFC7030 /cacerts to say something about creating
 an expiry/retry time in the certs-only CMC Simple PKI Repsonse.
 I don't see a date in a RFC5652 Signed-Only certs-only container that
 could be used to cause pledges to get the /cacerts earlier than the
 expiry time of the CA.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[





--
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] [lamps] EAP/EMU recommendations for client cert validation logic

2020-01-17 Thread Michael Richardson

Alan DeKok  wrote:
> Perhaps we should try?

> $ openssl s_client -connect smtp.mozilla.org:587 -starttls smtp > 
mozilla.crt
> $ openssl x509 -text -in mozilla.crt

You omitted an important part of that output, which is the name of the CA,
which I include below.
It could be that the CSP permits SMTP, or SUBMISSION service.
Ryan has suggested that CAs could put EAP-TLS (or EAP-TEAP) into their CSP,
and that also seems like an out.

Certainly, some of the excitement for ACME/Letsencrypt with DNS-01 challenge
is that it makes it easy to get a certificate for a non-HTTP thing.

I think we need to fix the lawyers, not the protocol.

The detail:
Issuer: C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA

   Subject: C = US, ST = California, L = Mountain View, O = Mozilla
   Corporation, OU = WebOps, CN = smtp.mozilla.org

But, let's do some more tests:
dooku-[/var/tmp](2.6.5) mcr 10051 %host letsencrypt.org
letsencrypt.org has address 162.243.166.170
letsencrypt.org has IPv6 address 2604:a880:400:d1::89c:7001
letsencrypt.org mail is handled by 5 alt2.aspmx.l.google.com.

dooku-[/var/tmp](2.6.5) mcr 10052 %echo QUIT | openssl s_client -connect
alt2.aspmx.l.google.com:25 -starttls smtp >| letsencrypt.crt

dooku-[/var/tmp](2.6.5) mcr 10053 %openssl x509 -text -in letsencrypt.crt|
grep Issuer
Issuer: C = US, O = Google Trust Services, CN = GTS CA 1O1
CA Issuers - URI:http://pki.goog/gsr2/GTS1O1.crt

What do CA's do?

dooku-[/var/tmp](2.6.5) mcr 10054 %host digicert.com
digicert.com has address 45.60.121.229
digicert.com has address 45.60.131.229
digicert.com mail is handled by 20 us-smtp-inbound-2.mimecast.com.

dooku-[/var/tmp](2.6.5) mcr 10055 %echo QUIT | openssl s_client -connect
us-smtp-inbound-2.mimecast.com:25 -starttls smtp >| digicert-smtp.crt
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global
Root G2

dooku-[/var/tmp](2.6.5) mcr 10056 %openssl x509 -text -in digicert-smtp.crt|
grep Issuer
Issuer: C = US, O = DigiCert Inc, CN = DigiCert Global CA G2
CA Issuers -
URI:http://cacerts.digicert.com/DigiCertGlobalCAG2.crt

What's that quote about doctor's fixing themselves?


--
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-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 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] [lamps] EAP/EMU recommendations for client cert validation logic

2020-01-08 Thread Michael Richardson

Alan DeKok  wrote:
alan> Many people use private CAs.  Many use public CAs.  *All* of them
alan> use id-kp-serverAuth.  Common EAP supplicants (MS / Apple / etc.)
alan> ship with known root CAs.  These root CAs are trusted by default
alan> for web browsing.  None are trusted by default for EAP.

How can anyone be using public CAs for EAP, if none are trusted for EAP, and no
public CAs issue certificates with id-kp-serverAuth?


--
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] EAP/EMU recommendations for client cert validation logic

2019-12-17 Thread Michael Richardson
orithm)

  2) 8366bis must be able to pin (?-public key), such that the operator can
 switch (public) CAs without invalidating the voucher.

There might be a (3) that I can't think of right now.

But, if these two requirements seem to contradict each other, then high-five
to you, you were paying attention :-)

--
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] Idea: New X509 Extension for securing EAP-TLS

2019-11-14 Thread Michael Richardson


On 2019-11-14 7:59 p.m., Alan DeKok wrote:
> On Nov 13, 2019, at 6:23 PM, Michael Richardson  wrote:
>> I think that the issue isn't, can we find or define a OID that has the
>> right semantics.
>> I think that the issue whether or not any public CAs are willing to
>> include that into a certificate.
>   That's less relevant than it may be.
>
>   The common practice for years has been to recommend self-signed or 
> "internal" CAs.  The original reason was that supplicants didn't do 
> certificate pinning.  So if they were configured to trust a root CA, they 
> would send user credentials to *any* EAP authentication server which had a 
> certificate signed by that CA.  With certificate pinning, they now warn if 
> the server certificate changes.
>
>   The other reason is that supplicant configuration is still largely a manual 
> process.  If admins need a complex process to configure the supplicant, then 
> adding a self-signed CA to the mix has near-zero cost.  And supplicant 
> vendors seem entirely disinterested in a standard way to configure them.

I understand.
If the authentication server is manually configured, then it matters not
in the last what OIDs might be in the certificate.

We believe that TEAP-BRSKI (or BRSKI-WIFI) will result in supplicants
being configured during an automated process.
This would involve getting the organizational root CA, and it could pin
the authentication server certificate, or
it could pin just a DN, TBD.  The OIDs might be be useful that point,
but I would generally find them not interesting.

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


Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

2019-11-13 Thread Michael Richardson


On 2019-11-13 7:40 a.m., Alan DeKok wrote:
> On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba)  wrote:
>> How does a public CA prove ownership of an SSID?
>   Do public CAs *always* verify addresses and/or telephone numbers, which are 
> normally included in certificates?

They are?  I've rarely seen it.
I think that if it's in the certificate, then they have verified them.
I can remember in the bad old days providing CAs with notorized articles
of incorporation, etc.
I haven't done that this decade though, and I haven't seen that kind of
info.
CAs won't include anything they can't verify.

>   Do public CAs verify that email addresses in the certificate work?

yes, they do by sending a challenge to it.
>   Do public CAs verify that the OIDs in the certificate match the intended 
> use-cases?

Most won't include OIDs.
>   Is there a global registry of SSIDs which the public CA could use to verify 
> the SSID?

No, SSIDs are a local matter.
One could (and I do), use FQDNs as the SSID.

That's the only way I can see this working.

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


Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

2019-11-13 Thread Michael Richardson



On 2019-11-13 4:07 a.m., Alan DeKok wrote:
> On Nov 12, 2019, at 11:43 AM, Russ Housley  wrote:
>> Can the extended key usage for EAP over a LAN ( id-kp-eapOverLAN ) solve 
>> this for you?  It is defined in RFC 4334.  A certificate for Web PKI should 
>> not include this extended key usage.
>>
>> RFC 4334 also offers a certificate extension that lists the SSIDs that are 
>> associated with the server.
>   That does sound relevant.  I wasn't even aware of that document.
>
>   While RFC 4334 offers the id-kp-eapOverLAN OID, I'm not aware of anyone 
> using it.  Even Microsoft supplicants still require the TLS web server auth 
> OID (1.3.6.1.5.5.7.3.1).

I think that the issue isn't, can we find or define a OID that has the
right semantics.
I think that the issue whether or not any public CAs are willing to
include that into a certificate.

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


Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

2019-11-12 Thread Michael Richardson


On 2019-11-12 3:53 p.m., Jan-Frederik Rieckers wrote:
> On 12.11.19 00:15, Owen Friel (ofriel) wrote:
>> One deployment consideration is if an operator wants to use a public PKI 
>> (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, 
>> before these extensions could be supported (as Alan alludes to), so it would 
>> also be good to define how this could work with standard RFC 6125 DNS-IDs / 
>> RFC 5280 dNSNames.
> I had a lot of thoughts about this topic.
> I am experimenting with certificates in EAP-TLS contexts and experienced
> the problems with getting a certificate with specific extension
> properties from our public PKI. (In my case a test certificate with a
> critical MustStaple extension)

You were trying to do a CSR with some extra attributes with a CA (using
ACME? Using LetsEncrypt?) and the CA ignored the things that it couldn't
verify?
> The Problem with dNSNames is that they are also used in other contexts
> (mainly HTTPS). There would be the possibility to define a specific
> prefix to bind it to a Realm without having the certificate being valid
> for the HTTPS host (e.g. eap-tls.uni-bremen.de for the realm
> uni-bremen.de) but I don't see the advantage in that.
> This will probably don't really lead to a change in the supplicants
> implementations.

I think you are saying that the problem with dNSNames is that web
servers use them/pay-attention to them, so CAs are careful what they put
in.  That's a reason to avoid that SAN in my opinion.  Toerless, in
draft-ietf-anima-autonomic-control-plane went the other direction, and
argued that only dNSNames have good interoperability, and so we have to
use only them.
> My deployment experience shows, that the certificate check is the main
> security problem in WPA2-Enterprise networks. I have seen instructions
> for installing WPA2-Enterprise networks where they have explicitly
> suggested switching off the certificate check, probably because it was
> too complicated for the users and would lead to people complaining at
> the IT department about the complicated setup.

So, as I understand it, the enrollment process for laptops/phones into
WPA-Enterprise does not include retrieving a set of anchors for that
connection.  Or that it is just too hard to do.   It works fine if the
devices are compelled by their corporate masters, but this fails for
BYOD, and it fails for cross-realm (which eduroam is).





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


Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

2019-11-12 Thread Michael Richardson


On 2019-11-12 7:15 a.m., Owen Friel (ofriel) wrote:
> This is also related to ongoing anima discussions about RFC 8366, and how it 
> can bootstrap trust when the pinned domain cert is a public PKI CA, and not a 
> private CA, and hence additional domain (or realm or FQDN) info is also 
> needed in order for the peer to verify the identity of the server.

While I'm familiar with this conversation, which I'm right now inspired
to call the the "Maria" problem
("How do solve a problem like Maria.  How do you a cloud certificate and
pin it down?")

I don't really understand what it has to do with the problem of an EAP
client, **which is not doing initial onboarding**, to validate a
certificate that it has received as part of EAP-TLS*.
> Its also relevant for ongoing Wi-Fi Alliance DPP discussions about 
> bootstrapping a supplicant onto an 802.1X network - after a supplicant 
> completes DPP and gets provisioned with a trust anchor - what if that trust 
> anchor is a public PKI? It’s the same problem.

I agree that this is the Maria problem, because the client has to pin
*a* CA and a SubjectDN (specifically a dnsName SubjectAltName), and you
want to allow the server to change public CAs.


>> -Original Message-
>> From: Emu  On Behalf Of Jan-Frederik Rieckers
>>
>> Thank you for your feedback.
>>
>> I was unaware of RFC 7585. I had a brief look on it and it seems that the
>> certificate part could be used for the goal I try to achieve.
>>
>> I'm not quite sure if the naiRealm should be used for validation on 
>> supplicants
>> for EAP-TLS. I would assume it would not be a security issue, but I don't 
>> have
>> enough experience to be sure about that.
>>
>> The main reason why I submitted this draft is my experience from the
>> deployment of eduroam at University Bremen.
>> With expiry of the used root CA and the needed migration, we have forced all
>> our users to use one specific outer Identity, to be sure the users configure 
>> their
>> devices with the eduroam Configuration Assistant Tool (CAT, cat.eduroam.org)
>> instead of a manual configuration, because in our experience manual 
>> configured
>> devices almost always lacked configuration for certificate checking.
>> But I just have experience in local deployment, the federation connections 
>> are
>> done at higher levels (country research networks), I don't have an insight 
>> there.

I skimmed your document before and I didn't understand it based upon my
quick read. Your text here helps me a bit.
In eduroam, the supplicant sees the TLSServerCertificate of the local
institution's Authentication Server, correct?
Is it not the case that for this to be validated that there needs to be
a path to the eduroam's root certificate,
which the client would have pinned?

You need to set the NAI correctly, because we have essentially an
SNI-like issue, in that the Authentication Server
needs to answer with it's eduroam certificate for eduroam clients, and
it might use a different certificate for other clients?

As I understand it, your ran into an issue because the root certificate
expired, and clients had pinned it, but they could find a new
certificate in DNS?







signature.asc
Description: OpenPGP digital signature
___
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


Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-11 Thread Michael Richardson

Eliot Lear  wrote:
>> Eliot Lear  wrote:
>>> Before we nail this down, it seems like we need to have a discussion
>>> about how best to onboard wired IoT devices in particular from an
>>> on-prem view.  The issue here is that EAP-TLS-PSK is useful for that
>>> purpose, as we discussed.  Now there is nothing particularly special
>>> about PSK and we could run with a naked public key pair as well in
>>> 1.3, but we have to choose something.
>> 
>> okay, so why do you prefer PSK?

> I do not.  But we need to have *a* flow for on prem onboarding.
> TLS-PSK is one approach, but there are others.  I just want a
> discussion before we nail this down, as I wrote.

>> 
>>> The fundamental question is what does a manufacturer stamp into the
>>> device and what is placed on a label.  We have a running example of
>>> DPP doing this for wireless with public key code, but that doesn’t
>>> get us to proper onboarding for wired – the signaling just isn’t
>>> there.
>> 
>> I don't understand this.  Are you saying that because it's wired,
>> people do not expect to scan anything?

> No quite the opposite- I’m saying that there is at least one way to do
> this with Wifi, but no way to do this for wired right now, an we need
> one.

So, can wired just be a degenerate version of wifi, where there can be only
one "ESSID", and there are no beacons to consider?

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 



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


Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-11 Thread Michael Richardson

Eliot Lear  wrote:
> Before we nail this down, it seems like we need to have a discussion
> about how best to onboard wired IoT devices in particular from an
> on-prem view.  The issue here is that EAP-TLS-PSK is useful for that
> purpose, as we discussed.  Now there is nothing particularly special
> about PSK and we could run with a naked public key pair as well in 1.3,
> but we have to choose something.

okay, so why do you prefer PSK?

> The fundamental question is what does
> a manufacturer stamp into the device and what is placed on a label.  We
> have a running example of DPP doing this for wireless with public key
> code, but that doesn’t get us to proper onboarding for wired – the
> signaling just isn’t there.

I don't understand this.
Are you saying that because it's wired, people do not expect to scan
anything?

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 



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


Re: [Emu] Re-charter text

2019-08-22 Thread Michael Richardson

Mohit Sethi M  wrote:
> At the same time, some new use cases for EAP have been identified. EAP
> is now more broadly in mobile network authentication. The group will
> update existing EAP methods such as EAP-AKA' to stay in sync with



> Out-of-band (OOB) refers to a separate communication channel
> independent of the primary in-band channel over which the actual

> EAP authentication is based on credentials available on the peer and
> the server. However, some EAP methods use credentials that are time or
> domain limited (such as EAP-POTP), and there may be a need for creating

I feel that the charter is too limiting if it names specific drafts like
this.  In effect, the charter is mandating adoption of specific documents.

If you agree, I will suggest some alternate text.

> In summary, the working group shall produce the following documents:

These read like milestones rather than areas of focus.

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 



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


Re: [Emu] EAP-AKA' and Re: WG adoption call for draft-arkko-eap-aka-pfs

2019-04-03 Thread Michael Richardson

John Mattsson  wrote:
>> I was always very sad that AKA did not get more uptake as it 
authenticates
>> the network to the phone, and therefore would have (as I understand 
things)
>> defended against "Stingray" like equipment used without judicial review,
>> requiring interceptors to significantly involve telco in such things, and
>> limiting who they would actually "catch".  ... I've heard other claims 
too.

> Several independent things here, first there are 4 different form
> factors for removable UICCs (aka "SIM cards")
> 1FF ("Full-size") = ID-1
> 2FF ("Mini-SIM") = ID-000
> 3FF ("Micro-SIM") = Mini-UICC
> 4FF ("Nano-SIM")

Yes, I knew that the original AKA form factor was different, and that this
was a limitation on why we still had "SIM" cards, but then I thought that
when we went to mini, that the form factors "converged", and you confirm that:

> On the UICC, there are either a SIM application (2G), an USIM
> application (3G) or both. If you live in a country that have 4G and do
> not use a very old SIM-card, your SIM-card have USIM and can do AKA
> with network authentication. Authentication to a 4G/LTE network
> requires a USIM and always use AKA with network authentication.

Good to know, thanks for this explanation.

> - the other is active false base stations. Many operators around the
> world has already turned off their 2G/GSM networks. The only reason
> this attack still works is that your phone happily connects to false 2G
> network is offers the best signal. Neither iOS (Apple) nor Android
> (Google) allows you to even manually turn off 2G. They both allow you
> to turn off 4G for battery savings but not 2G for security reasons. Ask
> the company that made your phone ;)

Sad to know.  Thanks for explaining this.

--
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] EAP and Transport Protocol

2019-04-01 Thread Michael Richardson

Alan DeKok  wrote:
>> being fairly new to the EAP world, I noticed that in some environment,
>> EAP is layered on top of other protocols - in particular RADIUS and
>> DIAMETER.

> EAP was originally over PPP.  Now it's mostly RADIUS.  There may be
> increasing use in the Diameter space.

I would say it differently, because radius and PPP are not equivalent.

EAP was originally over-PPP connected to over-Radius.
EAP is now more commonly over-802.1x connected over-Radius.
With Diameter replacing Radius in some environments.
EAP is "end-to-end" supplicant to Authentication Server.

(I know you (Alan) know this, but others might not)

> For TTLS, it can be:

> * Ethernet
> * IP
> * UDP
> * RADIUS
> * EAP
> * EAP-TTLS
> *  TLS
> *  EAP
> *  EAP-MSCHAPv2
> *  MSCHAPv2 credentials

> Yes, it's complicated.

:-)

> Open Source implementations of EAP are few and far between.  On the
> server side, it's only hostap and FreeRADIUS.  On the client side, it's
> hostap.

> There used to be "xsupplicant" and "open1x" on the client side, but
> those have been dead for 10 years.


>> In particular, the use of the

> Early truncation?

lack of fragmentation :-)

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works    |    IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[


--
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] EAP-AKA' and Re: WG adoption call for draft-arkko-eap-aka-pfs

2019-03-30 Thread Michael Richardson

Alan DeKok  wrote:
>   Let's be realistic about the IETF.  While we pretend that we have
> individual contributors, the reality is that large companies fund huge
> chunks of it.  Those companies effectively shield individual
> contributors from patent lawsuits.  i.e. no one will sue an employee of
> Cisco about a standard, they will instead sue Cisco directly.

Actually, nobody seems to sue the majors except other majors.
Nobody seems to sue small entities that have no money except patent trolls.

>   Michael and I have no such protection.  As an implementor of EAP-SIM
> and EAP-AKA, he may be personally liable.  As the person hosting the
> web site and source code, I may also be personally liable.

I don't think you can be sued for patent infringemenet for writing about
the patent, only for using it.Copyright, yes, but not patents.

>   And realistically, Open Source has driven the explosion of tech
> companies in the past 10 years.  I think few companies could have been
> profitable if they had paid license fees for an OS, web server, etc.
> So there should be a vested interest in protecting open source as part
> of the IETF standardization process.

I agree with you, and so it borders on seriously insulting to open source
authors to have these super-vague IPR claims show up from non-technical
lawyers.

Let me restate my original opinion:
   - if this is important to 5G, then anything that gets in the way of
 adoption is a problem.  If it's not important enough to fix the IPR,
 then it's actually that important.
   - adopting AKA is very important.


-- 
]   Never tell me the odds!         | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 




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


[Emu] EAP-AKA' and Re: WG adoption call for draft-arkko-eap-aka-pfs

2019-03-29 Thread Michael Richardson

Joseph Salowey  wrote:
> that consensus.  If you do not support adoption of
> draft-arkko-eap-aka-pfs-03.txt as WG item please say so by 2359UTC on
> 30 November 2018 (and say why).

I don't think that this was decided.
At least, I did not find a message about this in the archives!

I implemented server side EAP-SIM and EAP-AKA back 16 some years ago.
Based upon the many emails I got asking for help configuring EAP-SIM, and
the zero I got for EAP-AKA, I have never been sure to what extend AKA
really go out there.  Is the nano-SIM in my phone SIM or did it mutate into
AKA?  I never quite knew.

I was always very sad that AKA did not get more uptake as it authenticates
the network to the phone, and therefore would have (as I understand things)
defended against "Stingray" like equipment used without judicial review,
requiring interceptors to significantly involve telco in such things, and
limiting who they would actually "catch".  ... I've heard other claims too.

So anything that prevents AKA' from being taken on seems like a significant
thing to me!

I re-read pfs-04, and wound up reading draft-ietf-emu-rfc5448bis-04, which I
had not read before.  I found the extensive references to TS-3GPP.24 made
that document rather hard to read, but at least I can download them easily,
unlike some other SDOs.  There are also some awkward sentences where maybe
a pass through with a language editor would help.

for instance:
   Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF from the
   peer, the server checks that the suggested AT_KDF value was one of
   the alternatives in its offer.  The first AT_KDF value in the message
   from the server is not a valid alternative.  If the peer has replied
   with the first AT_KDF value, the server behaves as if AT_MAC of the
   response had been incorrect and fails the authentication.

I couldn't understand this at all.
You sure you want to call this EAP-AKA', and not EAP-AKA2 ?
That lone single quote seems to be asking for problems in code to me.

section 4:
   This mechanism comes in the form of the
   AT_BIDDING attribute.  This allows both endpoints to communicate
   their desire and support for EAP-AKA' when exchanging EAP-AKA
   messages.  This attribute is not included in EAP-AKA' messages as
   defined in this RFC.  It is only included in EAP-AKA messages.

Why not include it in EAP-AKA'?  You assume that there isn't a third
mechanism which should not be bid down to EAP-AKA' (some EAP-TLS or
something).

As I understand it, AT_KDF is an alternate KDF for EAP-AKA', and the
KDF is negotiated between the parties.   It seems like a reasonable thing to
do from a technical point of view, and the implementation seems rather simple
and straightforward.



I followed the link to the IPR page, but I have not (and won't) read the
patent.  Having read the pseudo code in section 6.3, I can't see how it's
significantly different than IKEv2.  If there is something novel here, I
don't know what it might be.

I found it interesting the IPR claim has the word "Possible", which
kind of makes one wonder:
Reasonable and Non-Discriminatory License to All Implementers with
Possible Royalty/Fee
I think that it is a template though, not something they chose.
The difference between RAND and RF is significant to open source projects.
Why is the claim duplicated, I also wonder.

If draft-arkko-eap-aka-pfs is important, I think it should be folded into
draft-ietf-emu-rfc5448bis.  It seems terribly useful to me, and if we are
going to have it, I'd rather have it by default.

Compared to when EAP-AKA was defined, the use of open source systems to
enable roaming is very very very significant.  If open source eco-systems
feel there is FUD here, then I think it is important to think hard.

Entities that want 5G to succeed, should think hard about whether litigating
this patent is more important than 5G succeeding for roaming.

Finally, I want to point to: https://lwn.net/Articles/780078/

-- 
]   Never tell me the odds!         | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 










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


Re: [Emu] Notes on session resumption with TLS-based EAP methods

2019-03-10 Thread Michael Richardson

If there is no legit use case for TLS resumption, then it seems that EAP
servers SHOULD disable TLS resumption.

--
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] Notes on session resumption with TLS-based EAP methods

2019-03-09 Thread Michael Richardson

Jim Schaad  wrote:
> I am finally getting caught up on this thread and I have found it to be 
very
> frustrating because it appears to make an assumption which I do not 
believe
> is warranted.

> I do not see any problems with allowing TLS session to be used across
> different types of EAP assuming that EAP correctly checks the output of 
TLS
> before continuing.  When a session ticket is issued for a TLS session it
> contains the authentication done by that TLS authentication session.  It
> does not contain any of the containing EAP authentication information that
> has been done.

I have been following along the discussion, and I think that I missed the use 
case.
Why are we having this discussion?

alan> i.e. a user starts with EAP-TLS, and then tries to "resume" his
alan> session, but this time uses TTLS.  It's not clear that anything in the
alan> spec forbids or prevents this.

What's in it for the user?
Is this an attack?
Does it avoid an interaction with a human?
Does it enable mobility between different networks?
Does this avoid some interaction with a two-factor authenticator?

--
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] FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt

2018-11-14 Thread Michael Richardson

Alan DeKok  wrote:
> For me, I would be fine with making the anonymous NAI mandatory.  I
> just don't see any end-user benefit to exposing their identities.  And
> there are benefits to privacy.

>> In terms of infrastructure, logging into a wireless controller, switch
>>or NMS and seeing hundreds of "anonym...@enterprise.co" makes an
>>administrator's life miserable. Most folks in a large enterprise
>>responsible for troubleshooting end user access do not have access to
>>the EAP server.

> If I were hard-nosed, I would say that's an internal management issue,
> and not a standards issue.  But I get your point, and there are ways to
> address this (see below).

It might be a lack of standard way to access logs of EAP server issue.

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


[Emu] ship and forget use cases for onboarding

2018-10-22 Thread Michael Richardson

{cutting CC of people, and we need to pick a WG list to discuss this on?}

Eliot Lear  wrote:
>> The Pledge already can
>> sign it's voucher-request, and since it includes the Registrar's key 
when it
>> does a proximity assertion, it's pretty good proof of possession for the
>> *Registrar*, but it might provide inadequate assurance to the MASA of 
it's
>> freshness.

> I think this covers the Joe Isuzu case that can fall out of the draft,
> and maybe one other.  The fundamental issue with the others is that the
> Pledge needs some reason to believe that it is really on the correct
> network.  Proof of possession can come in several forms, depending on
> the device, but we're assuming that there's no user input to the device
> available (e.g., no buttons, to touch screen, etc).  It could also be
> that the Pledge really doesn't want to validate proof of possession by
> itself.  In that case, there's no reason for the pledge to even know the
> proof of possession.

https://en.wikipedia.org/wiki/Joe_Isuzu  ... I asked google, and I'm not
quite sure I get the connection.

>> I would prefer that we split this into a different draft.
>>
>> I am very concerned that ship-and-forget is not a desireable property
>> in the IoT space.  It essentially means that the manufacturer has no
>> further
>> interest in providing any kind of updates for the device.I have
>> serious
>> cybersecurity concerns about such devices being out there (sitting
>> unpatched
>> and untracked in a warehouse somewhere), as well as significant
>> environmental
>> concerns about devices designed to die like this.

> It could also be the case that the device is intended to be deployed in
> disconnected environments.  I also think it's going to be a little while
> before certain classes of manufacturers will seriously be able to run an
> online MASA.  And I would like them to at least be able to consume a
> voucher, even if we need different sorts of transfer approaches.

It's not enough to say that they are going to be deployed in disconnected
environments.  It's that they one wants to drop-ship them from the
*manufacturers* warehouse to the disconnected location.

When one thinks about drop-ship to a disconnected location, one tends to
think about containers of humanitarian AID going out the back of a aircraft
(C-2, Hercules, etc.) with a parachute.   If anything, that situation is
probably *NOT* the case we are thinking about, because in that case the kit
would have already gone through the owner's warehouse (whether the owner is
a UN aid agency, some FEMA equivalent).  The entire kit could have been
onboarded (wirelessly) as it went *onto* the aircraft, or could even occur
as late as when it's on the aircraft.

And you said, "online MASA", when it could well be that it's an offline
MASA.  If you buy enough product, the manufacturer could well just put
a custom trust anchor in and give you the private key.  That's essentially
what happens in Industrial 4.0 802.15.4 deployments today.

So I'm saying, let's not invent a problem before we understand who actually
has the problem and make sure that the people who can solve the problem
are at our table.

--
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] Fwd: New Version Notification for draft-lear-brski-pop-00.txt

2018-10-22 Thread Michael Richardson

Eliot, thanks for this document. If nothing else, it means that
we BRSKI authors can deal with some review comments by pointing to "future
work" :-)

(A)"request-voucher-with-possession" <-- what about intent to traffic? :-)
  (for those that don't get the joke:
  
https://criminal.findlaw.com/criminal-charges/possession-with-the-intent-to-distribute.html
 )

if leaf out-of-band-claim to be set by the PLEDGE?
I think it is set by the Registar?

The document sadly ends too soon...

You say it is trying to do a few things.
  1) deal with middle value pledge,
 (and low-value pledges in very congested places)
 where an out-of-band supply-chain integration is unavailable,
 and the MASA has a any-registar policy for the device.

  2) provide a ship-and-forget mechanism.

It seems that the cryptographic POP mechanism is an ends to accomplish a
means, rather than a core goal of the protocol.The Pledge already can
sign it's voucher-request, and since it includes the Registrar's key when it
does a proximity assertion, it's pretty good proof of possession for the
*Registrar*, but it might provide inadequate assurance to the MASA of it's
freshness.   If the MASA could provide a nonce for the pledge to sign
(requiring another round trip, and even more online assurance), that would
provide even more proof.

Given that you pushed this out before today's cutoff, I am not upset
that there is so few details.  I am suspecting that in your thinking that you
created the three objects, and realized that could accomplish
"ship-and-forget" using a combination of them?

I also wonder if cryptographic-POP is being confused with "proof of
ownership", which I think is what you really want to accomplish.

If one assumes some machine readable (QR) code that comes with the product,
then there are a few things one can do to differently.  One of the things
that I have thought a lot about is that one uses the printed code in the
Registrar to establish a relationship with the MASA.  That is, one creates
the supply-chain-integration by using the QR code with some zero-knowledge
proof (I think that PAKE is the latest one) to establish that one is the
legitimate Registrar for the product.  One can do this as *any time*
(some mumble about the lifetime of the CA of the Registrar's key), and
the product will be enrolled correctly at any future time.

About my joke (A) above, I think that ship-and-forget is an interesting
goal, and in particular, if also may enable desireable "traffic"ing.  That
is, if the manufacturer can transfer the product to my ownership without any
online interaction, then presumably, I can also *resell* the device to
you using the same lack-of-interaction?



   > In addition, some manufacturers may prefer not to require the
   > existence of a MASA.  In these circumstances proof of possession to
   > the device is required.

I would prefer that we split this into a different draft.

I am very concerned that ship-and-forget is not a desireable property
in the IoT space.  It essentially means that the manufacturer has no further
interest in providing any kind of updates for the device.I have serious
cybersecurity concerns about such devices being out there (sitting unpatched
and untracked in a warehouse somewhere), as well as significant environmental
concerns about devices designed to die like this.

I am trying to think of devices where this makes sense.  I come up with a few
things: single-use medical devices (like bandages, syringes, etc.),
prophylactics and other single-use sex toys,  things you eat, and some
variety of devices that might be called "spy craft".  In each case, I'm
having difficulty knowing what the "smart" aspect of the product is, other
than simply tracking it's existence and current stocking location. A smart
package containing a dumb device is a good idea, but it seems like something
that would be better recycled, and in any case, it's not ship-and-forget
for the packaging.

So this is why I think that splitting ship-and-forget mechanism into another
document would let us treat it better.  In particular, I want to know who is
going to deploy using such mechanisms, and if they are at the table now.
I guess I shall add a slide to my ANIMA BRSKI stack about this in an attempt
to get feedback.

I suspect that there is a category of devices that some think of being
ship-and-forget which might actually be ship-to-holding-company.
Holding company leases to end user for period of time.  End user identity
is never communicated back, and might be very much pseudonymous.
I'm thinking about car-rentals, hotel rooms (full of devices), ...

--
]       Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

--
Michael Richardson , Sande