Re: [Emu] Adoption call for eap.arpa
Mohit Sethi wrote: > As far as I can tell, we will not be the first ones using such a > scheme. ".home.arpa." defined in RFC 8375 > (https://www.rfc-editor.org/rfc/rfc8375.html) allows sub domains. It says: > "For an administrative domain that uses subdomains of 'home.arpa.', such as a > homenet, the recursive resolvers provided by that domain will be able to > answer queries for subdomains of 'home.arpa.'" It's not at all the same thing :-) home.arpa is a real anchor which home routers can serve names into using DNS. (Replacing ".local" [which implies mDNS], and .lan, which some home routers use) > We are taking a more conservative approach where subdomains need expert > review and registration before they are allocated and can be used in > deployments. I would not characterize it this way at all. I suspect we can have what we want, we just need to explain it to the IAB well enough. Unfortunately too late in the week for a hallway conversation. I found some IESG to talk to at the last break, but no IAB. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
Alan DeKok wrote: > 1. Instead of servers deciding the EAP method based on the username >part of the NAI, the EAP method could be decided based on the sub domain >under eap.arpa in the realm portion of the NAI. Thus a peer wanting to >be provisioned would use provision...@noob.eap.arpa or >provision...@tls.eap.arpa depending on whether it supports: EAP-NOOB or >EAP-TLS for provisioning. Leaving the username semantics to individual >provisioning drafts (example: draft-ietf-emu-bootstrapped-tls) might be >beneficial in the long run as explained below. > That's a good idea. My once concern is if IANA / IAB would allow for a > separate sub-registry for the subdomains, and allow EMU to control that > registry. I think its an IAB question. IANA with implement whatever we ask for. It would be EMU's Expert Reviewers that would decide, I guess. It's late in the week to pigeon hole someone, but ... maybe we can find someone. Is a sub-domain the only technical solution? I'm sure we will need to answer that. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
Alexander Clouter wrote: >>> On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote: >>>> My understanding here is that the EAP server and client will not >>>> authenticate each other in EAP-TLS, and all the authentication will >>>> be done in the " captive portal ". So why recommend EAP-TLS as a >>>> provisioning method? Just send the identifier "por...@eap.arpa" and >>>> then jump to a " captive portal ". Is that OK? >>> >>> So for OOB provisioning (ie. get an IP to access a captive portal) >>> the conversation would be: >>> >>> >>> EAP-Identity Request <<< EAP-Identity Response[por...@eap.arpa] >>> >>> EAP-Success >>> >>> Sounds sensible. >> >> I don't think it's that straight forward. For Enterprise-WiFi we >> still need cryptographic keys for the WiFi 4-way handshake, so >> establishing a TLS-Tunnel is needed to derive the WPA keys. > Nice catch. Doing this is significantly better than either unencrypted wifi (w/portal), or encrypted WPA-PSK wifi. So yes, we always want to run EAP-TLS to generate keys. This document is related to https://datatracker.ietf.org/doc/draft-richardson-emu-eap-onboarding/, (which I'll repost on Saturday), but modularizes the work into smaller pieces. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
I've read draft-dekok-emu-eap-arpa, I think it important step in getting a number of other efforts underway. Please adopt. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt
Heikki Vatiainen wrote: > I haven't worked with CBOR, but I'd be interested to know if, for > example, how careful we need to be with serialiser/deserialiser to > avoid problems similar to exponential expansions attacks [1], etc. TLVs There are no entities like in XML, so that won't work. CBOR now includes a "packed" format which is essentially a bespoke compression system for CBOR, with the decompressor defined. Encoders (compressors) can be as complicated as one likes. The billion_laughts attack might be possible with packed CBOR, but as a CBOR Protocol user, you would be justified if you just said, "no packed CBOR" -- 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] New Version Notification for draft-janfred-eap-fido-02.txt
Alan DeKok wrote: > ALPN would be much simpler, I think. The downside there is that > every time you rev the protocol, you have to register a new ALPN name. > That's annoying. I don't know if it would be acceptable to register an > ALPN _prefix_, and then just self-allocate versions. But, revising the protocol involves a new RFC, so I don't see the logistical problem of registering a new ALPN. Maybe it's annoying during development to have to stick a new value in and not know what it's going to be? -- ] 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] New Version Notification for draft-janfred-eap-fido-02.txt
Jan-Frederik Rieckers wrote: > I just posted a new version of the EAP-FIDO draft. > We had some discussion on the name "EAP-FIDO" at the last IETF and we > have come up with some name options since, but none of them resonate > with me yet. I see the issue. > I have started a pad with different name options, everyone is invited > to chime in: https://md.kif.rocks/VcVOg34pSFWh64Ev_JsG6Q I contributed EAP-SeaTAP. I also don't like any of the options listed, but EAP-FIDO won't fly with me. > I am planning to work on an implementation during the hackathon to have > a better understanding and can identify possible missing spec and the > different error conditions that we need to signal. :-) -- 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] New I-D: A new EAP method called EAP-FIDO
Dan Harkins wrote: > RCM means that MAC addresses can't be relied upon anymore; good. The > solution is not EAP-TLS in the home though, it's getting away from the > "single passphrase per SSID" model that Wi-Fi came up with 20+ years > ago and still cannot move beyond. For the record, it's possible to send > a password identifier in the WPA3 exchange to support multiple > credentials on a single SSID (it's part of the 802.11 standard) but the > largest mobile phone company refuses to support it so it's kind of > dead-in-the-water. I didn't know that WPA3 supported a password identifier (I guess: a "username" concept). That's pretty significant I think. Do you know why "largest mobile company" thinks it is a bad idea? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New I-D: A new EAP method called EAP-FIDO
Jan-Frederik Rieckers wrote:
> Firstly: deleting the EAP-specific configuration (as in: "Dear client,
> I don't know you, please stop asking"). This can be as simple as
> sending a simple message, but has the problem that faulty
> configurations in the beginning can't be debugged, because the moment
> the client connects it gets the delete request and deletes the profile.
:-)
> But actually I don't know if **provisioning** the credentials in-band
> is such a good idea. Because, in order to provision the credentials,
> the user needs to prove that they are authorized, and how would they do
> that?
Is the user provisioning a new device, or is the network provisioning a new
user?
> I admit that with the current idea of the protocol flow the
> OOB-registration adds a small layer of complexity for the
> administrators, but I gather that it will be much more easy for the
> users. And the additional workload for the provisioning is well
> invested
Agreed.
> With the current movement the FIDO alliance is pushing this is actually
> a great step, because the FIDO Passkey that is already provisioned for
> logging into the account in the web can now simply be used for network
> access as well.
I hope this turns out to be true.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New I-D: A new EAP method called EAP-FIDO
Jan-Frederik Rieckers wrote: > Administrators don't fully understand the EAP methods, and they usually don't > have time to dig into that. They just want it to work. I agree that we have problems. > With the suggested way to pin the PKI to the one used to provision the > credential I see several problems: > * How to store? > Since the credential is not necessarily used on the same device that the FIDO > credential was registered (example: YubiKeys that are registered by the admin > and then issued to the user), the information needs to be stored in the > registration information somehow. I'm not sure if that is possible and/or > manageable. It seems to me that this can be solved, but I agree that it isn't solved yet. So we probably need a configuration knob here. One thing that I know a few people have talked about is having a standard configuration format for clients. > And another question remains: What exactly do I store? "I used WebPKI" or > "The trust anchor was the ISRG Root X1" or "My cert was issued by > Let'sEncrypt R3" or "the SHA256-FP of the CA cert that issued the server > cert was " I think this is something we should actually answer. > This is not to say that there aren't use cases out there where CA pinning is > useful and the spec should not forbid that possibility, but I don't want to > specify a protocol, where, 20 years from now, people say "Why do we need an > external configuration tool again to configure the trust parameters?" > For MDM environments like company wifi, where you have your well-maintained > private CA and (more or less) complete control over your end-devices, CA > pinning is ok. +1 > But we don't have this in BYOD environments like education institutions. And probably in fewer and fewer enterprises given BYOD. As a goal, we need to migrate to more use of EAP-TLS in home environments. RCM requires it in the end. > Because the cert parameters are not implicit from information that the user > is willing to configure (usually username and password), the eduroam folks > developed a tool that helps with the secure setup of the Wifi. And having > experienced the First-Level-Support, many people complain about "Why is it so > difficult to get on the wifi at the university, can't you just give me the > wifi password and everything works like at home? What do I need this app > for?" Yeah. It doesn't need to be so hard. But, PSK is just not actually secure at home. It's just that on-path attacks at your home are often not worth the effort. > And pinning the CA in BYOD environments causes a lot of problems in the > future, that are likely to wander out of sight and only re-surface -- in > the best case a short time before, in the worst case at the time -- things > break and now the admins need to act quickly. And this reaction also involves > the end-users, that need to reconfigure their devices and that's never a good > idea, because the latency of end-user action is immense (esp. if they are not > technically versed) -- 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] New I-D: A new EAP method called EAP-FIDO
Alan DeKok wrote: > Not explicitly, but implicitly. > I think the way out here is to not mandate the use of WebPKI. Instead, > we can just say that the EAP certificate should be issues by the same > (or equivalent CA) to the one which was used to provision the initial > FIDO credentials. > In practice, this means WebPKI most of the time. :) Actually, that's a stronger statement anyway. It means that the choice of CA has essentially been pinned, so you'd not be vulnerable to attacks like ComonoGate. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] eap.arpa domain in draft-ietf-emu-bootstrapped-tls
Alan DeKok wrote: >> I think that this is a mistake to be so specific. >> I don't think the supplicant should know/care, at this point, what kind of >> access it is going to get. I liked what we we had done with eap-onboarding >> where you get limited network, and then if DHCP says, via the DHCP option >> (or the RA option) that there is a captive portal, then it should do that. >> Or, it could say do RFC8995 (BRSKI) via GRASP announcement. >> Or... > There have been long discussions about not tying EAP to DHCP. I forget > which RFC it is, but there's an IAB architectural document which says > this is a bad idea. There is no connection here. EAP(nobody) gets you a useable L2. L2 makes DHCP possible. There is no link, and they are not tied. > I think the supplicant should know what kind of access it's getting. > This is also a signal to the RADIUS server as to what kind of > authorization to send to the NAS / switch. When you write this, what I am hearing: the end user has to know everything about the network they are joining. And that's exactly what I think we are trying to avoid. > In contrast, if there's only one kind of on-boarding access, > authorization has to be done through DHCP which has much more limited > capabilities for that. There are possibly many different ways depending upon where you open the lid of your laptop, phone, chromebook, personal IoT device. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] eap.arpa domain in draft-ietf-emu-bootstrapped-tls
Alan DeKok wrote: > On Aug 30, 2023, at 6:29 AM, Owen Friel (ofriel) wrote: >> >> Hi EMU Chairs, >> >> I was looking to see if any minor updates are needed to draft-ietf-emu-bootstrapped-tls-03 before IETF 118 and WGLC. >> >> There was one outstanding action from IETF 117: >> >> Do we want to say there is an eap.arpa domain? Yes, but >> not clear this draft is place to do that. Chairs to ask IAB to do >> this. > I had discussed this off-line with the chairs, and they were waiting for me to do something. I've bene trying to get TEAP out of the way, but I've just posted an "eap.arpa" draft now. > It's still very rough, but the idea is "use someth...@eap.arp". And > then fill in some suggestions. So, this replaces draft-richardson-emu-eap-onboarding-03 which would use onboard...@eap.arpa. (Hmm. I keep thinking it was going to be "nob...@eap.arpa") > HTML: https://www.ietf.org/archive/id/draft-dekok-emu-eap-arpa-00.html You use por...@eap.arpa here. I think that this is a mistake to be so specific. I don't think the supplicant should know/care, at this point, what kind of access it is going to get. I liked what we we had done with eap-onboarding where you get limited network, and then if DHCP says, via the DHCP option (or the RA option) that there is a captive portal, then it should do that. Or, it could say do RFC8995 (BRSKI) via GRASP announcement. Or... -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
Alan DeKok wrote: > On Aug 26, 2023, at 2:13 PM, Michael Richardson > wrote: >> Are you saying that Windows 11 also has implemented (accessible via >> "insider program" only)? > I believe that TEAP is generally available in Windows 11. since some things have been clarified, are we sure then that it's on the side of the new text? (I'm asking as shepherd to record Implementation Status) -- 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] WGLC on draft-ietf-emu-rfc7170bis-11
Heikki Vatiainen wrote: > Test with Windows 11 and eapol_test - EAP-TLS followed by EAP-MSCHAPv2 Are you saying that Windows 11 also has implemented (accessible via "insider program" only)? Bernard could you confirm? -- 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] I-D Action: draft-ietf-emu-rfc7170bis-13.txt
Alan DeKok wrote: > This draft addresses the final open issues. I've updated the github > repository to verify and close the open issues. I have updated the shepherd write-up. I don't see any issues at that level now. The document is ready for AD review I think. -- 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-rfc7170bis-12: minor findings
Alan DeKok wrote:
>> I suggest re-adding the subsection for PAC TLV with a brief note that
>> it's deprecated. This would serve as reminder that TLV number 11 did
>> exist and it would also keep the section numbering unchanged making it
>> easier to compare RFC 7170 and its updated version. This is a purely
>> an editorial idea.
> I'm not sure it's useful to document things which aren't used.
> But It's useful to compare section numbers. I'll add a paragraph
> explaining that it was removed, and why.
That's a good idea.
TLV number 11 was the PAC. It is documented in {{RFC7170}}, but is
considered deprecated.
In the IANA considerations, the other TLVs can be updated to "THIS DOCUMENT",
leaving 11 pointing at 7170.
--
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] WGLC on draft-ietf-emu-rfc7170bis-11
Eliot Lear wrote: >> We don't need or want anonymous ciphersuites here. > We should keep the TLS-POK work in mind. I didn't find an obvious draft about that in the TLS WG. -- 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] WGLC on draft-ietf-emu-rfc7170bis-11
Heikki Vatiainen wrote: >> On Aug 17, 2023, at 5:02 PM, Michael Richardson >> wrote: >> > section 3.9.: what is "server unauthenticated provisioning" > >> (sounds like TEAP-BRSKI?) >> >> Yes. > Should it be noted that this provisioning method is only available with > TLS 1.2 and earlier because the method requires anonymous ciphersuites? > It confirms to the reader that this is the intended case. If we are talking about an RFC8995 (BRSKI) mechanism then: a) It requires that the Peer defer validation of the Server's certificate until later on when another signed artifact is received (RFC8366 voucher). b) The server still validates the Peers' client (IDevID) certificate. We don't need or want anonymous ciphersuites 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] WGLC on draft-ietf-emu-rfc7170bis-11
ate a TLS
>>> ClientHello handshake message, in which case the TEAP server MAY
>>> allow the TEAP conversation to be restarted, or it MAY contain a TEAP
>>> response with a zero-length message, in which case the server MUST
>>> terminate the conversation with an EAP Failure
>>
>> What are some situations where a peer would expect to do a restart?
>> Some kind of temporary resource exhaustion or something?
>> ENORANDOMNUMBERSLEFTPLEASEWAITFORMORENEUTRINOS ??
> Is "I dunno" a good response here?
I'm trying to understand a situation grave enough to cause a failure, yet not
grave enough that the end points could essentially try again. (vs restarting
from scratch, or failing over to another server)
>> Also, I wonder if the word "peer" above means "Peer", or just either
>> end. To that end, I found "Peer" very confusing at times.
> It means "TEAP peer", to match the earlier "TEAP server"
Okay, could it always be "Peer", and never "peer" then?
>>> It is NOT RECOMMENDED to use certificates provisioned via TEAP with
>>> any other protocol which uses TLS.
>>
>> Honestly, this renders the entire point of the provisioning aspect of
>> this probably moot.
> I'm wary of provisioning a client cert with TEAP, and then using it
> for
Yes, that's certainly a concern.
And for random laptops users, it's probably a bad thing.
But I know Eliot wants to use this for IoT identity provisioning.
> But that being said, it also doesn't make a lot of sense to
> authenticate (somehow?) and then get a client certificate. The main
> benefit of the client certificate is that you can now change your
> password at will, and you don't need to update the EAP configuration.
What's a password?
>> Section 4.3, about TLV rules. Given that EAP fragments, but is
>> subject to RADIUS and other layers dropped packets.. And that TLS
>> assumes a TCP-like transport for its records, there is a question
>> about whether one should pack more TLVs into a single TLS record, and
>> let EAP fragment, or put fewer TLVs in, and have fewer fragments. Is
>> there any advice here? We can't put certain things together, but can
>> we split them out more? What if we care more about loss due to lost
>> fragments, vs round-trips?
> RADIUS defines retransmission rules. I don't think we need to worry
> here about lost fragments.
Sure, but the question is: is it better to have 5 1K things, or
1 5K thing? Assuming that the TEAP level TLVs can be broken up that way.
>> I suggest when listing the contributors for 7170, that they be listed
>> using the markdown contributors: method, as that results in XML that
>> is machine parseable. There is also a {{{First Last}}} for kramdown
>> that results in XML.
> Sure. I can't find much in the way of actual examples...
author:
...
contributor:
- name: First Last
email: m...@example.com
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-acceptable-urls/blob/master/opsawg-mud-acceptable-urls.md?plain=1#L32
--
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] Is the CSRattributes use in draft-ietf-emu-rfc7170bis a greenfield?
Alan DeKok wrote:
Alan> On Aug 17, 2023, at 5:34 PM, Michael Richardson
Alan> wrote:
>>
https://www.ietf.org/archive/id/draft-ietf-lamps-rfc7030-csrattrs-06.html#name-alternative-use-of-csr-temp
>> ( https://youtu.be/biGtfqj7zgM?t=1640 )
>>
>> describes a new, simpler way to to CSR Attributes, basically with a
>> fill-in-the-blanks CSR. Doing ONLY this method would seem very
>> attractive for protocols which might be greenfields: that is no
>> implementations out there yet.
>>
>> This question to the group is whether or not there are any RFC7170
>> implementations ("Peers" or servers) which currently implement this at
>> all,
Alan> That being said, it would be difficult to depend on a document
Alan> which isn't published. Perhaps we could just make a recommendation
Alan> to use the new method, and leave it at that?
You already have a normative reference to the LAMPS CSR attributes document.
Alan> I would very much like to get this document done and
Alan> gone. Delaying it more is IMHO a bad idea.
--
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
[Emu] Is the CSRattributes use in draft-ietf-emu-rfc7170bis a greenfield?
> Servers and peers MUST follow the guidance provided in
> [I-D.ietf-lamps-rfc7030-csrattrs] when creating the CSR-Attributes
https://www.ietf.org/archive/id/draft-ietf-lamps-rfc7030-csrattrs-06.html#name-alternative-use-of-csr-temp
( https://youtu.be/biGtfqj7zgM?t=1640 )
describes a new, simpler way to to CSR Attributes, basically with a
fill-in-the-blanks CSR. Doing ONLY this method would seem very attractive
for protocols which might be greenfields: that is no implementations out
there yet.
This question to the group is whether or not there are any RFC7170
implementations ("Peers" or servers) which currently implement this at all,
and if not, then would the group like to recommend only using this newer,
simpler method?
[(b) - since the CSRattrs document is normatively referenced, additional
review would be very welcome and very timely. I expect to put out an 07 by
next week with some ASN.1 editorial fixes]
--
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] WGLC on draft-ietf-emu-rfc7170bis-11
"services" from it.
(What are these services, if they aren't things that lead to an MSK? Ah,
subsequent sections. Forward reference to 3.9.3 please)
Mention is then made of "provisioning data" as a service.
I think this section could use a rewrite. I suggest using this section to
say WHAT TO DO, and then in Security Considerations, tell us what happens
when that advice is not followed. That way implementers aren't dealing with
a mix "DO X", with "watch out for Y"
3.9.1: tls-unique vs TLS 1.3 again.
I think, unless there are in-the-field, two interoperable, versions of this
section, that it be removed from this document, and put into a new document.
The text in 3.9.2 is new, and frankly not all that useful.
CSRs are not that complex, because 99% of the information that could be
included in a CSR is useless, and CAs throw it out. I don't think this
document needs to repeat the need for a CSP.
> It is NOT RECOMMENDED to use certificates provisioned via TEAP with
> any other protocol which uses TLS.
Honestly, this renders the entire point of the provisioning aspect of this
probably moot.
I see that "4.2.18. CSR-Attributes TLV" references:
> Servers and peers MUST follow the guidance provided in
> [I-D.ietf-lamps-rfc7030-csrattrs] when creating the CSR-Attributes
I will start a new thread on this topic.
> 4.2.19. Identity-Hint TLV
I think that this should be mentioned in section 3.
Probably 3.2 or 3.4.
Section 4.3, about TLV rules.
Given that EAP fragments, but is subject to RADIUS and other layers dropped
packets..
And that TLS assumes a TCP-like transport for its records, there is a
question about whether one should pack more TLVs into a single TLS record,
and let EAP fragment, or put fewer TLVs in, and have fewer fragments.
Is there any advice here? We can't put certain things together, but can we
split them out more?
What if we care more about loss due to lost fragments, vs round-trips?
5.1 finally talks about TLS 1.3 exporters.
section 5.7 says: "negotiate down", and I think the common term in the
literature is "bid-down attack", and I think reviewers will prefer that term.
s/Man-in-the-middle attacks/on-path active attacks/
7.4.1 describes a mechanism where TLS 1.2 can use re-negotiation to get
confidentiality of client certificates. That shouldn't be introduced in the
SC, but needs to be described much easlier, and then referenced.
Also, there is BCP14 language in the SC, which I really prefer never to see.
It should be in the main body.
Important nits:
-- The abstract seems to indicate that this document obsoletes RFC7170, but
the header doesn't have an 'Obsoletes:' line to match this.
== Outdated reference: draft-ietf-emu-tls-eap-types has been published as
RFC 9427
Some other nits worth looking at.
Normative references that probably could be informative:
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/info/rfc7170>.
(yes, because we are obsoleting it, so you don't have to read it!)
Informative references that probably need to be normative:
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985,
DOI 10.17487/RFC2985, November 2000,
<https://www.rfc-editor.org/info/rfc2985>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>.
MAYBE:
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
I suggest when listing the contributors for 7170, that they be listed using
the markdown contributors: method, as that results in XML that is machine
parseable. There is also a {{{First Last}}} for kramdown that results in XML.
--
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] WGLC on draft-ietf-emu-rfc7170bis-11
wrote: > Alan has issued -11 of draft-ietf-emu-rfc7170bis. He > believes it covers all of the outstanding issues that needed to be > resolved. We held up the WGLC until we could have our session at IETF > 117. With post-117 changes incorporated, now's seems like the time for > the WGLC to go forward. Please post your comments to the mailing list > by August 28th. Even a "good to go" is genuinely helpful input. If you have, or plan to implement, the document shepherd would like to know. -- 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] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
Alan DeKok wrote: > I'll note that the peer can always simply stop doing EAP once it's > fully provisioned. i.e. it doesn't need to get an EAP Failure or EAP > Success from the server. However, such behavior is unfriendly to the > server. It leaves the server with a blocked EAP session that has to be > eventually timed out. "simply" --- well, that's really exactly what SHOULD happen. The use of EAP_Failure on the part of the EAP Server is almost a formality. It probably needs to occur for the benefit of the Authenticator: it might have have state that can get flushed. Really, the supplicant should ALREADY be gone. In RFC8995, we defined two telemetry results, such that if the provisioning *failed* that one continued with the onboarding connection in order to report stuff. BUT, that if it worked, that one was supposed to reconnect with the new identity and report success. (This is less important than detailed failure) >> Under the hood, housekeeping operations that update credentials are >> just updating entries in one or more tables that index to the same >> device as before, and so absent a change in role of the device, one I'm unclear if you are talking about renewal of an LDevID, or the first creation of the LDevID. I agree that renewal could be done without any forced break of the connection, and probably one wants to do exactly that. >> shouldn't expect much in the way of a change of authorization policy. >> There's one BIG exception: expired credentials. Here again, this is >> server-side policy that might involve sandboxing the device, setting >> the result to EAP Failure in a request action TLV, opening a trouble >> ticket, firing an employee, or some such. > For me, that's just "failure to authenticate". It's already handled > reasonably well. And since EAP failure is returned, no change of > authorization is necessary. The user is simply not allowed network > access. Agreed. > I would strongly prefer to avoid requiring RADIUS CoA / Disconnect. > They're good to have, but not always possible. If the Access-Request > packets are sent across a TLS tunnel through a NAT gateway, it is > impossible to send CoA to the NAS. Point. > I'll see if I can put some wording around "authorize based on > _provisioned_ credentials, and not _connecting_ credentials" > Alan DeKok. > ___ 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] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
Alan DeKok wrote: > The simplest way to do this may be to require that any provisioning > phase result in EAP Failure. The inner tunnel can return the > credentials, crypto-binding TLV, and a Result TLV which indicates > success. But the final outer EAP packet should be EAP Failure. > I'm unsure if this is a substantive change to the document at this > phase. Given that no one has implemented PKCS provisioning yet, it may > be acceptable to make this change. This seems reasonable to me. -- 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] I-D Action: draft-ietf-emu-rfc7170bis-08.txt
Alan DeKok wrote: >> Alan DeKok wrote: >>> * CAs should validate (somehow) any CSR they receive, to check that >>> the contents are reasonable >> >> I guess this is the new section 3.2.8. > Yes. >> There are quite a number of subtlies here. First, the CSR is not >> really that complex :-) >> >> more importantly, there are not really any standard ways to >> communicate with CAs about exceptions, about things that in the CSR >> that need to be added or ignored. > I don't think there's a possibility for such negotiation. I'm not > even sure such negotiation would be a good idea. I mean, between the EAP-peer and the CA. (Not between the EAP-peer and supplicant) > That doesn't solve the issue of what the EAP peer does, though. > Mostly it could be "have a GUI / API to expose a few fields for > configuring the CSR", and that's about it. I think that's probably even excessive. It would be good to have an operational document that says what operators actually need what. I think that it's mostly a question of if you give operators options, they will just do weird things for not well understood reasons. I think that the client certificate needs a SubjectAltName, probably an rfc822Name, but MAYBE another GeneralName. And, maybe, a DN. There is no CSRattributes that can specify the DN today. > The only thing this document can do is to suggest "here be dragons", > and then move on to other subjects. It may take operational experience > to fully understand what are the best options here. CSRattributes gives lots of power, but I don't think the end user needs any input other than inputting their email address. (Assuming, it can't be gotten from elsewhere on the system. I'm thinking @me.com, @live.com, ubuntu-1 account) >> Probably some reference to the 4.2.18. CSR-Attributes TLV section. >> And I see that you have dealt with the Base64 goof (RFC8951), and the >> new format. I would welcome your comments on the latest document, and >> to David van Oheim's proposal that is coming up in some slides at the >> next meeting. TEAP is likely a good greenfield for his simplified >> view. > I'll take a look. It's not written up, having been discussed in detail only last Wednesday. I'll get slides posted to LAMPS in the next week. But, the short of it: Here is an CSR, please fill in the blanks. -- 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] I-D Action: draft-ietf-emu-rfc7170bis-08.txt
Alan DeKok wrote: > * CAs should validate (somehow) any CSR they receive, to check that the > contents are reasonable I guess this is the new section 3.2.8. There are quite a number of subtlies here. First, the CSR is not really that complex :-) more importantly, there are not really any standard ways to communicate with CAs about exceptions, about things that in the CSR that need to be added or ignored. The CAs do what they want, and the TEAP/EAP-peer is pretty much left with, either fail the CSR after examining it, or just trust. Or use an integrated CA or a proprietary API. Frankly, this is what I recommend: run your own CA. Probably some reference to the 4.2.18. CSR-Attributes TLV section. And I see that you have dealt with the Base64 goof (RFC8951), and the new format. I would welcome your comments on the latest document, and to David van Oheim's proposal that is coming up in some slides at the next meeting. TEAP is likely a good greenfield for his simplified view. signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [IANA #1269174] Early review: draft-richardson-emu-eap-onboarding (IETF 116)
Amanda Baber via RT wrote: > https://datatracker.ietf.org/doc/draft-richardson-emu-eap-onboarding > The IANA Considerations section needs to include the "Domain Name > Reservation Considerations" sub-section described in Section 5 of RFC > 6761 (we’ve failed to ask for this in recent years). Hi, thanks for the suggestion! Subject: New Version Notification for draft-richardson-emu-eap-onboarding-03.txt Name: draft-richardson-emu-eap-onboarding Revision: 03 Title: EAP defaults for devices that need to onboard Document date: 2023-04-02 Diff: https://author-tools.ietf.org/iddiff?url2=draft-richardson-emu-eap-onboarding-03 We've added section 7.1, with the template filled in. Is this the right way to do this? 7. has the IANA request, with a subsection doing the template. (to be clear: eap.arpa requires *no* processing changes in any DNS places. It's just a unique name that we need as a REALM) -- 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] Call for EMU agenda items for IETF 116
Peter Yee wrote: > We are now about one month out from IETF 116. Please inform the chairs > if you have items for discussion before the EMU WG at the upcoming > meeting in Yokohama. There are no meaningful changes to draft-richardson-emu-eap-onboarding. Our work on running code is much slower than anticipated, but it is occuring. It's not clear to me what else the document can/should say. -- 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] [Acme] I-D Action: draft-ietf-acme-integrations-13.txt
Owen Friel \(ofriel\) wrote: > This addresses all issues raised on the mailers. The issues and > associated fixes can all be seen at: > https://github.com/upros/acme-integrations/issues?q=is%3Aissue+ > The authors noticed one issues related to Joe Salowey's feedback on > tls-unique channel binding: > An update for TEAP is underway that can be used to address channel > binding in TLS1.3 using RFC9266. which I think is specified in draft-ietf-emu-tls-eap-types-04, section 2.2. > However, there is no currently planned update for EST RFC7030 to > specify how to use RFC9266. EST only references tls-unique. How should > we proceed here? AFAIK, a TLS1.3 exporter just needs a string to be specified somewhere. Where should we specify this? -- 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] New Version Notification for draft-richardson-emu-eap-onboarding-02.txt
internet-dra...@ietf.org wrote: > A new version of I-D, draft-richardson-emu-eap-onboarding-02.txt > has been successfully submitted by Michael Richardson and posted to the > IETF repository. > Name: draft-richardson-emu-eap-onboarding > Revision: 02 > Title:EAP defaults for devices that need to onboard > Document date:2023-02-04 > Group:Individual Submission > Pages:9 > URL: https://www.ietf.org/archive/id/draft-richardson-emu-eap-onboarding-02.txt > Status: https://datatracker.ietf.org/doc/draft-richardson-emu-eap-onboarding/ > Html: https://www.ietf.org/archive/id/draft-richardson-emu-eap-onboarding-02.html > Htmlized: https://datatracker.ietf.org/doc/html/draft-richardson-emu-eap-onboarding > Diff: https://author-tools.ietf.org/iddiff?url2=draft-richardson-emu-eap-onboarding-02 This version has no substantive technical changes, but editorial changes to clarify some language. Implemention of this has been delayed. -- 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-rfc7170bis-02.txt
Alan DeKok wrote: > This revision has the changes discussed during the interim which was held yesterday. The new document should probably reference which errata it fixes. Some have done this in the document, some with actual Informative references. > There are still open questions on two errata: > https://www.rfc-editor.org/errata/eid5770 > https://www.rfc-editor.org/errata/eid5775 I tried to handle the meeting notes yesterday, and I have some suggestions to make this more tractable for everyone. I imagine that we have to do another virtual interim to get through the rest. (They could be design team meetings, that's up to the chairs) First, some a slide per errata with links to all the right places can be helpful for engaging participants in the issues. It also helps with the WG history. If not, then I suggest prepping the agenda into the note taking space, with all the links you need, and then screen share your view of the notes. Second, if you send fewer pixels, then scaled, they will be bigger on the recipient end. Share only a tab or a window, not your whole screen. (Mac has challenges here which not every browser seems to get right, due to the "window" including the File/Edit menus...) "Works best in 640x480" is still true :-) -- 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] Adoption call for RFC 7170bis
Alan DeKok wrote: > We have "something" implemented today as TEAPv1. Whatever it is, > it's shipped by multiple vendors on tens of millions of devices. Plus, > there are multiple other vendors planning on shipping TEAP support in > Q2 2023. > We can rev TEAP, but we can't change existing implementations. And > any new rev will be deployed in the time frame (at best) of 12-18 > months. > If we document 7170bis now "as implemented", that can be done in a > short time frame. We then have the freedom to do whatever we want with > TEAPv2. But I'm wary of not documenting TEAPv1, and I'm wary of > delaying that documentation in the interest of doing a TEAPv2. I agree. > I'm not even sure what we'd do for TEAPv2. There isn't much point in > changing the key derivations. The current one is arguably suboptimal, > but it works. I wouldn't see a need to change it for something > "better" in a TEAPv2. I think it depends on what we learn about deployed TEAPv1. It could be that there are things that Eliot wants to do that turn out to be impossible because it would break deployed code (that he cares about) if done in TEAPv1. -- 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] Second WG Last Call for EAP-AKA' PFS
John Mattsson wrote: > Thanks for the suggestion, Michael. Currently we are unfortunately > using xml. The aasvg version seems nice. I make an issue on GitHub and > see what we can do. You can do it with XML, but it's a manual process. The RPC might be able ot do this for you at AUTh48. signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Second WG Last Call for EAP-AKA' PFS
The document looks good to me. Thank you for the _7.5. Post-Quantum Considerations_ section. If the authors are using kramdown, they could consider enable aasvg processing of their ascii art diagrams. For instance: https://www.sandelman.ca/tmp/fig1.svg -- 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] I-D Action: draft-ietf-emu-bootstrapped-tls-01.txt
Jan-Frederik Rieckers wrote: > In the introduction (Section 1 and and 1.3) the phrase "catch-22" is > used twice. I needed to look up the phrase to know what it meant. It makes me sad that the term is not better known. It's also the name of a bestselling book (and a mediocre movie), but I'm told that the author did not make the term up. It's a great book. I wonder if there is a better saying that is more universal, or perhaps, in the explanation of catch-22 we could include other cultural references to the same concept. > sure that I am not the only one who does not know the meaning of this > phrase, so I suggest the authors reword this so it is clear to everyone > what is meant by that, regardless of knowing the respective saying. -- ] 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[ ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for EAP-DPP
I have read draft-friel-tls-eap-dpp-05. I have no objection to the WG working on such a thing, but I think that there is actually quite a lot of work left to do. I think that the section 3, which explains the EAP connection (and the motivation for the work) should probably come before the extension and the cryptographic explanation! I find the document quite weak even in section 3. I think that the EAP server (Authentication Server) is meant to use the OOB public key to authenticate the new device. I'm rather vague as to how the Authentication Server knows what identity to use to look the public key up, and how the privacy of this identity is preserved. Does the device get any indication that it has been plugged into the correct network? Is there any authenticatin of the Authentication Server? While I acknowledge you are not trying to implement BRSKI (RFC8995) or SZTP (RFC8572), it would be good if your Security Considerations addressed some of the same issues that those documents deal with. -- 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 onboarding at ANIMA WG
Alan DeKok wrote: > The current draft is missing some points: > * SNI for the supplicant to indicate which domain it would like to access > * supplicant examination of the server certificate to see which domain it accessed This is actually a bit of a complex question, I think. If the realm announced is eap.arpa, wouldn't the SNI have to have that? Given that, and given that it's a domain that you can't get a certificate for, it seems that the supplicant will have to accept whatever certificate is returned on faith, until the device is online enough to do more. This is not surprising in RFC8995(BRSKI), as it typically creates a provisional TLS connection to the Registrar, which is *later* authorized by an RFC8366 voucher. Can we do this with supplicants? I imagine so, but the write-up in the document could be challenging. -- 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
[Emu] EAP onboarding at ANIMA WG
Topic/Title: EAP defaults for devices that need to onboard Name of Presenter(s): Michael Richardson (with Alan DeKok) Length of time requested: 5 minutes (new work) Document If applicable: https://datatracker.ietf.org/doc/draft-richardson-emu-eap-onboarding/ Alan and I have written a -00 document (just posted), on using unauthenticated EAP-TLS (no client-side certificate) to allow a supplicant (a pledge) to get enough IP connectivity in order to run an authenticated onboarding solution, such BRSKI (RFC8995). As described in the document, the network would put these clients onto a (L2) quarantined network, much as it would if a device was found that did not pass it's remote attestation process (cf: RFC 5209 and friends). While there are proposals to run BRSKI over EAP using TEAP, etc, the challenges of MTU, limited amount of traffic that can travel over EAP, and the hassle of implementing yet-another mechanism seem excessive to us. Enterprise networks already have quarantine/captive-portal (V)LANs with full isolation between hosts. Smaller networks can easily afford to add such things, and there are projects to isolate every single IoT device into it's own L2 domain until it proves it needs to communicate. We are working on code. I'm happy to present at EMU as well. EMU may wish to adopt this document. But first, I think that the ANIMA WG, as a consumer of this, may like to say if it satifies a need. -- 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] Provisioning, configuration, etc. and EAP
Alan DeKok wrote: > On Mar 28, 2022, at 9:00 AM, Michael Richardson > wrote: >> Well, this is not something I'd do as part of onboarding, but rather >> as part of _configuration_, and I agree that it would be better to >> just use IP for that. > I'd argue that onboarding is just a special case of configuration. Yes, many have tried to that, including NETMOD. But it's a special case. I don't mind using IP, but to do that, >> The issue is that new SSIDs have to deployed over hundreds of access >> points. > Use the normal SSID. Unauthenticated EAP-TLS. User ID of > "provision...@eap.arpa". But that could be even worse in many settings! To do this safely means setting up layer-2 isolation for the device so that it can't talk to (or attack) any other device (nor be attacked). Or do you have some other idea on how to support this? >> This new "LAN" has to have VLANs deployed for it, and if done wrong, >> might need DHCPv4. > Yes. I'm not sure that VLANs are a limited resource, or are > difficult to provision. GVRP has existed for a while... It's not just the cost of the VLAN, it's the management functions associated with them as well. But, I'm just the messenger here: I actually would prefer this. -- 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] Provisioning, configuration, etc. and EAP
>>> reconfiguration - how does a device with an existing configuration >>> update it? When / where / why / how? >> >> Why is this step different than configuration? > I put that in, in part because of EAP-CREDS. In part because I'm not > sure that updates fall within the bounds of provisioning / onboarding. > i.e. I already have something, and I can get onto the network. How > often do I refresh those credentials? What happens if my authorization > changes? How do I get told if my credentials are withdrawn? I understand. For mechanisms like BRSKI (and CSP/MATTER, and probably UPC UA) where the end product of onboarding is a certificate issued to the device, then the question about when to refresh is mostly given by the notAfter parameter. In most cases one should start refreshing those credentials at the 50% mark. The ACME WG is discussing having the certificate renew point be better specified (in the ACME protocol), but I think that we will learn from this and wind up with something in the certificate if the protocol can't carry additional meta-data. > Perhaps this could better be described as policies and signalling for > refresh and updates of provisioned data. The act of doing the update > is just provisioning. Knowing when / where / how / why to do that > update isn't quite part of the provisioning process. Agreed. There are advantages of having renewals spread across time, but there are also disadvantages as it spreads the failure signal across time as well which makes it harder to see that there is a real problem. -- ] 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] Provisioning, configuration, etc. and EAP
Alan DeKok wrote:
>> 64K is plenty to run RFC8995. Probably we can get away with a total
>> of less than 10K exchanged in the worst case situations, with 2K being
>> more typical.
> That's good, but I still have concerns with the process of using EAP
> for, well, almost everything.
> Anonymous / unauthenticated EAP-TLS exists. I'd like to know why
> that's unacceptable for provisioning general-purpose devices.
> For example, see any number of device management products. These
> products download large amounts of configuration, and even applications
> to end-user devices. This process is part of provisioning the device,
> and can't be done via tunnelling that data in EAP. So if we're not
> using EAP for most of that complex provisioning, why not just use the
> same methods for all of it?
Well, this is not something I'd do as part of onboarding, but rather as part
of _configuration_, and I agree that it would be better to just use IP for that.
>> The cost is that it has to be setup and available across a potentially
>> large enterprise situation. At the small scale of one or two home
>> routers, it's just not a problem.
> I'm not clear how a large enterprise causes any issues. For my
> proposal, just put records into DNS, and various data into web pages.
> Anyone with corporate credentials can then get on the secure WiFi
> network.
The issue is that new SSIDs have to deployed over hundreds of access points.
This new "LAN" has to have VLANs deployed for it, and if done wrong, might
need DHCPv4.
There is a limit in air-time for the number of beacons that the APs have time
for as well, but it's not a concern, AFAIK, until you get into the O(10^2)
range.
> It's 2022... why is it difficult to get onto a friends WiFi network,
> securely, and easily?
Two out of three?
--
] 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] Provisioning, configuration, etc. and EAP
Alan DeKok wrote: > EAP implementations are limited to exchanging ~64K of data before > supplicant and/or server gives up. If there is a need to exchange more > data than this, it's impossible. Configuration data tends to grow over > time, because of a tendency to just use the existing system, even > though it isn't really intended for that use. People tend to (ab)use > existing systems in surprising ways, too. 64K is plenty to run RFC8995. Probably we can get away with a total of less than 10K exchanged in the worst case situations, with 2K being more typical. > This method also has a cost. Administrators now have to set up > additional services in order to do provisioning. This may not always > be possible. As Eliot pointed out, there are also security issues with > exposing additional servers (EST, etc.) to unauthenticated users. Specifically, my original notion was to have an SSID called "ONBOARDING", which was unencrypted. (I would run on DHCPv4, which makes smartphones give up and go away. IPv6-LL only) I can live with it being trivially encrypted via EAP-TLS with a "well-known" username/password like we do with the "ietf" network at meetings. The cost is that it has to be setup and available across a potentially large enterprise situation. At the small scale of one or two home routers, it's just not a problem. We will have to give up on WPA-PSK for the home, because RCM (Madinas) just can't cope with maintaining policies for different devices when the devices all have the same PSK. -- 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] Provisioning, configuration, etc. and EAP
Alan DeKok wrote: > I would split this up into: I'm gonna quibble with your choice of terms, because there has been some progress/convergence in the terminology. This is good news, because sharing terminology is an important leap forward. > bootstrapping - starting from nothing, or almost nothing, how does a > device get on the network, and get a minimal configuration enabled? > provisioning - how does a device with some existing network access / > configuration get onto a new network, perhaps with a new identity? The term "onboarding" is now used for this step. (Yes, BRSKI gets it wrong) I'm a bit unclear about how these steps differ. The term "provisioning" has come to mean when the "almost nothing" is provided to the device in the factory. That's come to mean an IDevID, but it can also mean an (e)SIM, or other long-term shared secret. The term "commissioning" has come to mean provisioning + configuration. That is, the device is recognized, it is joined to the network, and it might be told what it's role in the Superbowl 3000-drone display is. > reconfiguration - how does a device with an existing configuration > update it? When / where / why / how? Why is this step different than configuration? There is a plan to unify/contrast the terminology in section 4 of: draft-irtf-t2trg-secure-bootstrapping/ but that section hasn't happened yet. -- 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] Question for draft-ietf-emu-tls-eap-types-03
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
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
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
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
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)
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)
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?)
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?)
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
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] Moving towards less security in 2020 - OCSP
Mohit Sethi M wrote: > So we were already saying "SHOULD" for OCSP in 2008 when RFC 5216 was > published. And now 12/13 years later, some people in the working group > are suggesting to make the security stance weaker. For what? Some > speculative insecure future deployments? Please note that EAP-TLS is > currently implemented in billions of devices and used in many high > security deployments. I don't think that people were saying it should be weaker than SHOULD. I also think that there is a distinction between MTI and mandatory to use which has gotten lost. And I think that there is also a significant distinction between a server supporting answering OCSP staples, vs a client being forced to ask for it. If the CA doesn't put any OCSP data into a certificate, then it can't be used. That's a local decision. -- 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
{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
Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic
Alan DeKok wrote: > While, there are commercial supplicant products, these products are > overwhelmingly used by the enterprise, on computers owned by the > enterprise, and managed by the enterprise systems. They have zero > impact on the average user. Today. But, since a goal here was for IoT devices, this changes things: 1) Enterprises want to manage IoT device onboarding, and they overwhelmingly want to use EAP/1x. 2) IoT devices don't have users and can't even load a non-standard XML configuration. > In practice, an SDO like the Wifi Alliance, 3G / 4G / 5G groups can > demand their members put root CAs into devices. That can even demand > that the CAs follow certain policies. > I have no such power. So it's unhelpful to say "just start your own > CA!" Well, even if you were the Wifi Alliance, you'd also have a mindshare/bootstrap problem. -- 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 CAs for IDevID and device certificates
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
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.
entication 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]
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
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 ...)
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 ...)
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
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
ic key algorithm) 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
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
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
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
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
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 ...)
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
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
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
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] RFC 7170 (TEAP) errata
Alan DeKok wrote: > TBH, I haven't seen an implementation. > I suspect that the lack of implementations is why these questions are > only coming up now. >> My feeling is that it would be better to make the TLV length variable >> with the hash length. However, I do not see why truncating would work >> as well. > My $0.02 is to allow a variable TLV length. > I think it's OK to leave these as errata now. I'm not sure that any > existing EMU document would be appropriate for these changes. Apparently there will soon be a mechanism deployed which will let people see the documents with the errata *applied* on the rfc-editor.org site, so it's a good idea to formally accept the errata, make a decision and then you can generate a diff. It seems like having the TLV length be variable is the right answer. (I don't have a TEAP implementation yet) -- ] 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
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
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
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
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
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
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] Review of draft-pala-eap-creds-00
Alan DeKok wrote: > This specification addresses the problem of providing a simple-to-use > and simple-to-deploy system for credentials management by extending > the EAP protocol to support credentials provisioning and management > functionality. In particular, the EAP-CREDS method defined here What do you mean by credentials? Are you talking about certificates or something else? It seems that certificates are mentioned. EST inside of TLS-EAP already is being discussed, with BRSKI as the introducer. This protocol seems to re-invent EST (RFC7030). -- ] 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] FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt
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
{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
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/
