d subset of OIDs. So you can't just add an OID and get it
used.
The current implementations seem to be OK, inter-operable, and secure. But
it would be good to document this behavior, and explain why it's necessary.
I'll see if I can suggest some text.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
does PEAP (with inner MS-CHAP), or TTLS (with inner MS-CHAP. TTLS
with inner PAP / CHAP doesn't provide them.
If we're willing to live without those indicators for other TLS-based EAP
methods, then draft-dekok-emu-tls-eap-types is essentially done. It needs some
minor updates,
penSSL a
bit, it seems that it has no code which can *ever* send an "access_denied"
alert. Also, it's not clear that the TLS state machine allows for this alert
after exchanging application data.
So in short, it's relatively easy to add protected success indicators for
othe
far and aware
more complex to implement.
For us, the code changes to support TLS 1.3 are maybe a few hundred lines of
C. The difference between (1) and (2) is maybe 50 lines. Having multiple TLS
exporters is maybe 100 lines. (3) is much larger, and much more error prone.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
TBH, just leaving it as draft-13 or -14 is fine. The main important change
for me is to mandate the use of TLS alert as a secure altReject indicator, and
a delayed close_notify / commitment message (after the client cert) was a
secured altAccept indicator.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
may be tied to a WiFi SSID.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Feb 7, 2021, at 6:11 AM, John Mattsson
wrote:
>
> Alan DeKok wrote:
>
>> The document should explain this in detail, and suggest which message flows
>> are preferred, and which >ones MUST be supported. It should explain what
>> happens when resumption is
r sending one byte of application data instead of close_notify.
For the simple reason that it better unifies the code paths for all TLS-based
EAP methods. That being said, we definitely need *a* protected success
indication.
Alan DeKok.
___
Em
ecification to note the corner cases / error conditions,
describe them, and explain why they're wrong and should not be used.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Feb 5, 2021, at 2:53 PM, Alan DeKok wrote:
> The TLS layer generally *will* produce TLS alerts. The application has the
> choice whether or not to send them. i.e. it should just discard the TLS
> alerts, and instead send EAP-Failure.
Typo, sorry. It "could" di
that the diagrams have to be correct, and accurate. Please explain
*why* the diagrams have the content they do.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
as such, no".
The TLS layer generally *will* produce TLS alerts. The application has the
choice whether or not to send them. i.e. it should just discard the TLS
alerts, and instead send EAP-Failure.
My suggestion here is to document and mandate this
ld impose no additional burden on
implementations/
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
i.e. the first ticket is in the same packet when the server sends "TLS
Finished".
After the server receives the client certs, it goes "whoops", and issues a
*new* session ticket in the next packet.
So no packet should have *two* session tickets.
Alan DeKok.
_
, a refreshed NewSessionTicket message
is sent to the client.
...
I'm going to spend some time implementing various things and digging into
the protocols / implementations / APIs in more detail. The outcome should
hopefully be clear answers as to who does what
e client cert, because IIRC, that closes the TLS connection (server
side), and prevents it from sending TLS alerts.
> If a mandatory authenticated alternative success indication is introduced in
> EAP-TLS 1.3, I do not think any future additions to TLS 1.3 wou
pon it anymore the
> way that one could with 1.2.
Yes.
It looks now like the main issue is getting an *authenticated* success from
the EAP server to the EAP peer. Neither CloseNotify, not the Commitment
message are sufficient for that purpose.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
d to do that. If it's not clear *why* content is in the draft,
then we should figure it out. That's why I'm asking questions, and why I would
very much appreciate answers to those questions.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ure, spec for EAP-TLS 1.3. The current
discussion does not give me confidence that we're making progress
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Feb 2, 2021, at 4:16 PM, John Mattsson
wrote:
>
> Alan DeKok wrote:
>
>> The diagram suggests that it's possible for the EAP-TLS server to separate
>> the "TLS Finished" >messages from the "NewSessionTicket" message. There is
>> no guid
ft. The meaning of
> and requirements for the -13 commitment message now seems quite unclear.
An in-progress draft is not an authoritative source of information. The WG
is discussing what the commitment message means, with an eye to making
recommendations for the draft, and implement
to how this is done. After spending some time going through RFC
8446 and OpenSSL docs / code, it's not clear that this separation can be
enforced by the application.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t IETF 110
> meeting, but -14 looks like the only thing that can reach agreement to be
> published at this point.
IMHO we are still nowhere near agreement. There are many open questions
which have not been resolved.
Alan DeKok.
___
the client to send an
> alert, which is a non-starter in my opinion.
I agree.
> B. If we settle for an extra round trip, we can use close_notify and make
> sure the client always has at least 1 chance to send an alert.
Presuming that we
rter keys are available *before* the client cert has
been validated. This "fast path" helps with non-EAP protocols. But makes life
more difficult for EAP.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
rovide APIs to get the raw
> certs.
Yes. We expose the certs to the policy engine, along with various fields.
Having the TLS exporter use more data should just be about updating some code.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https:/
On Feb 1, 2021, at 11:26 AM, Eric Rescorla wrote:
> Yes, this is what I have in mind. So, maybe there's never any need for the
> server to say "I won't say anything more" after just one round trip?
I think so, yes.
That means of course EAP-TLS will always require 4.5 roun
nd TLS alerts *before* the
CloseNotify. So the client has to either wait for those, OR an explicit
CloseNotify, to see if it's (a) rejected, or (b) authenticated
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
the server likes the client cert, Figure 1 of draft-13 shows
the next packet is EAP-Success. So the client has no *authenticated* way of
telling that it has been authenticated. Any party to the conversation could
send a blank EAP-Success (which is 4 bytes of unauthenti
cation would occur quite quickly after a request).
> How easy it would be to get things back onto 0x0d in the future is less
> clear, though.
As an implementor, I fervently hope to *not* support an "ad hoc" EAP type for
the next 10 years.
My preference is to get this right, even it means more delays.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
1.2, and potentially a major problem.
There is a goal to get EAP-TLS working in 3.5 rounds. That's a good goal,
but I'd like to be sure that it doesn't come at the expense of security.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t what the commitment message does, and
why it's needed here, and not for TLS 1.2.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
atter if it's interoperable, because
people won't deploy it in production. Implementors are already verifying code
behind the scenes in builds which aren't shipped to customers. So the type
code is less of an issue, because that interoperability is "inter-engineer",
and not "
ion-3.1
So if we later discover that EAP-TLS is flawed, we can only deprecated
EAP-TLS, and create a new EAP-TLS "prime", with a new EAP type code.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
is perhaps possible that (as John noted downthread) the text
> about the commitment message was badly written, and that just changing the
> surrounding description could work, but that gets back to the question I
> mentioned above of what properties EAP-TLS act
On Jan 29, 2021, at 8:10 AM, Alan DeKok wrote:
> Then our choices are:
>
> a) draft-13 in February. There are multiple interoperable implementations,
> including Microsoft, FreeRADIUS, and hostap / wpa_supplicant.
>
> b) ??? in 202
.
TBH, implementors have already had multiple informal discussions and calls.
One more wouldn't make much difference.
Alan DeKok
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t we're changing that.
The TLS review so far seems to have stalled. Which means to me that the TLS
feedback isn't important enough to finalize it. So we should just say
"thanks", and stick with draft-13.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
against an external database. For slow databases, TLS session resumption can
result in significantly lower load, and significantly faster re-auth times.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
esumption, but
TTLS / PEAP / etc. required it.
And of course, this ignores the timeliness of the changes. I suspect that
silence from the WG means that consensus is "we can afford to wait another year
for EAP-TLS to be finished".
Alan DeKok.
quot;when can we get this
finalized?" "March" would be late. "July" is a major problem.
> On Jan 12, 2021, at 10:22 AM, Alan DeKok wrote:
>
> On Jan 11, 2021, at 7:08 PM, Martin Thomson wrote:
>> I was not exactly. I was thinking that EAP-TLS uses the
is
simple, and it's easy to understand. But if it causes issues with TLS review,
we can change it.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ntations, and
there's less for IANA to deal with.
But maybe the TLS people have a strong opposition to using the context in this
way. In that case, it's ugly, more work for everyone, but still possible to
just append the hexified EAP type code to the label.
Alan DeKok.
___
git diff src/modules/rlm_eap/ | wc -l
89
It's fine.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Jan 5, 2021, at 11:05 AM, Michael Richardson 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 E
to the EAP peer. Those messages can then be used to
debug deployment issues.
The exact method of doing this is less important. The "0x00" octet works
now, so I'm happy with it. But if TLS review decides that should change,
that's fine, too.
Alan DeKok.
these fields.
Removing MS-MPPE-Send-Key and/or MS-MPPE-Recv-Key will destroy global WiFi.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ich relies on TLS negotiation. But if using CloseNotify makes
deployments substantially more difficult, then that is a very strong reason to
avoid it.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
to wait another year or two to pick
these labels. This work is becoming timely, and there is no reason to delay it
any more.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
own EAP type
value. This practice greatly simplifies implementations.
See https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 for more
information.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
n the
> information given in the resumption. [...]
>
> I'm not sure I understand how these two sentences fit together. Is it
> trying to say that "if there could be a different decision, you
> definitly have to re-check, and we recommend just always re-checking
> since that's timpler"?
Pretty much, yes.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
by the server and
might be a 22-character ASCII string.
I think it's best to just refer to Section 3.3.1, for the format of the
PeerId. And then note that the construction in Section 3.3.1 is compatible
with HTTP, and does not require escaping.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
, implementation,
and deployment issues with respect to EAP-TLS.
You have a point in that many of these issues are applicable to other
TLS-based EAP methods, too. Updates to those methods can reference this
document. There's no need for a separate document.
Alan DeKok.
__
+1
> On Oct 29, 2020, at 1:37 PM, Eliot Lear
> wrote:
>
> Hi Max
>
>> On 29 Oct 2020, at 18:30, Max Pala wrote:
>>
>> Hi Eliot, all,
>>
>> In our industry we solved this issue by requiring OCSP stapling if and only
>> if the certificate being validated carries the OCSP URI in the
the topics are related. But draft-ietf-emu-eap-tls13 is more
about the protocol, and draft-ietf-emu-eaptlscert is more about deployment
considerations.
For me, this means that security issues such as certificate revocation
checking belong in the protocol specification, not in
with no version changes would be disruptive to multiple products.
TBH, there isn't a lot of point. We should just document what
implementations do today. Then, suggest that everyone move to TLS 1.3, and
define entirely new derivations there.
Alan DeKok.
___
uld be fine to make OCSP stapling optional.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
gets paid by the number
> of published pages.
Or if the authors wish to give practical, timely, advice to implementors of
EAP-TLS.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Section 2.5 already states that 0x00 is the
plaintext, and that plaintext length != encrypted length.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
the absence of further discussion, I would suggest staying with 0x00.
I'll go poke some code. :)
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
d hoc" stream cipher, and isn't doing hashing (as such).
I suggest then that we simply use the TLS-Exporter, as you suggest. Perhaps:
IPMK = TLS-Exporter("EXPORTER: Inner Methods Compound Keys", ISK, 60)
Which then mirrors the deri
ng.
> My understanding is that is would add an extra roundtrip without any clear
> benefits compared to sending an encrypted 0x00 application data.
That's a reason to stick with sending 0x00, then.
Alan DeKok.
___
Emu mailing list
Emu
hwhile thing to do when the
> implementation is anyway updated for TLS 1.3.
Can we use the same hash functions as above? If so, what would the text look
like?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
this change, then it's possible.
Otherwise we're stuck with what we have.
> Editorials:
>
> - "in Section Those"
> - formatting of the list in section 5
I'll fix that, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ve the "send 1 byte of 0x00" hack, as it's
philosophically weird
I think it would be acceptable to send 1 byte of 0x00 when an EAP failure
occurred. We know that the user won't be authenticated, so we don't care about
extra data stuffed into the TLS session.
Alan DeKok.
ll just go delete support for LEAP. There's just no
reason to allow it to be used.
I'll also add the NAK in the access-Reject as per RFC 3579.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ect because deployments don't encounter this kind of
> role reversal in practice.
Yes, I haven't seen EAP -Request sent to RADIUS servers, other than for LEAP.
I'm not sure what you mean by "protection against retransmissions" though.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Failure inside of an EAP-Message.
Since hostap doesn't really have policies in it's RADIUS server
implementation, it doesn't implement this check.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
network instabilities, etc. And a response of "our implementation is
compatible with the RFCs" is not appropriate when that behaviour is causing
problems for others.
I would agree with at the minimum technical errata being reported for RFC
3748 and/or RFC 3579. I'm not sure that updated documents are required, though.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
s:
Therefore systems which expect to perform accounting for the session
SHOULD cache an identifier which can be used in subsequent accounting.
In RADIUS, this would involve sending back User-Name or CUI in the
Access-Accept.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t.
> However I believe that the intent is to use the full PSK blob, or some
> digest thereof, as a key to lookup the corresponding cached handshake
> data.
>
> Perhaps this could be made clearer?
I agree.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
; methods that do need to keep the connection open? i.e. PEAP/EAP-TTLS/TEAP
When those methods send application data, they don't need to do anything else.
When those methods use fast reconnect, they don't send application data. So
the other EAP methods should also send "close notify&q
I suspect that most uses of TLS will *always* send application data. Which
makes EAP-TLS an outlier. Hence the need for hacks like "send application data
as one octet of zero".
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
I've posted a new revision of the document which should address all of your
comments. Thanks again for the detailed review.
> On Jun 2, 2020, at 3:29 AM, Jorge Vergara
> wrote:
>
> Hi all,
>
> I’ve attempted/completed a prototype implementation of EAP-TLS, PEAP,
> EAP-TTLS, and TEAP
.
> "No known security issues" is a pretty low bar. Who has looked (how
> hard?) and what are their qualifications?
Perhaps it should say "little security analysis has been done"
> Section 6.1
>
> I don't think RFC 6696 needs to be a normative reference.
Sure.
> Acknowledgments
>
> I guess we should mark eid 5011 as "Hold For Document Update" before
> this document gets published (it's currently just "Reported")?
Yes.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
teroperability.
So I think it's fine to send the one octet as *encrypted* data, and not
*plaintext*.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
fixing:
>
> NEW
> [RFC5247] did not define Session-Id for Microsoft's
> Protected EAP (PEAP). For consistency with the EAP-TLS definition
> given in [RFC5216] Section 2.3, we define it as:
> END
Done.
Thanks.
Alan DeKok.
___
> needed are fairly simple and after the above issues are solved I could
> complete my prototypes.
I'll take a look this week. I also hope to have FreeRADIUS updated for TLS
1.3, too.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ond
> and third GSM triplet respectively."
Fixed.
> (6) Section 3. It would be useful to describe the prior work in Security
> Considerations. Specifically, "These updates to not modify the Security
> Considerations outlined in RFC5247."
Fixed.
I'll publi
ging in new work, when the updates to
TTLS and PEAP are languishing. That document is small. There's been positive
feedback. There have been only minor issues which have been addressed in the
most recent version.
I think that we should be able to accept, last call, and publish the docu
quot;,
> S-IMCK[j-1] | MSK[j], 60)
> To
> IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",
> S-IMCK[j-1] | IMSK[j], 60)
> For TEAP.
I've made the change, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
se it? Why?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
et for this idea to people who are willing
to pay $100K+ for a commercial Diameter product.
Such a strong limitation means that this idea is likely to be dead in the
water even before it starts. I would therefore suggest expanding the use-case
for this proposal.
Alan DeKok.
ww.ietf.org/archive/id/draft-vanrein-eap-sasl-00.txt
That draft looks reasonably clear.
> The other work is progressing in
> https://tools.ietf.org/html/draft-vanrein-diameter-sasl-03
I have no opinions on that draft.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
. Is there
anything controversial, missing, etc?
* What are the barriers to adoption and publication?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
eryone else who has
this data its buried 6 levels deep in a large organization.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
es not have to mirror the
>> organizational hierarchy. For successful EAP-TLS authentication,
>> certificate chains should not contain more than 2-4 intermediate
>> certificates.
>
> I would make a stronger statement here. There is absolutely no reason for the
> certi
vacy
> 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.
Changing that may be very, very, diff
ge it.
I will do some minor updates and release a new version shortly.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
gt; Or are you saying that you want to avoid EAP-TLS (cert), EAP-TLS (psk),
> EAP-TLS (pwd), etc
Having EAP-TLS-(TLS variant) is probably wrong. Just use EAP-TLS (full).
That lets us configure TLS parameters in TLS, and not in EAP.
Alan DeKok.
___
SK ones from right?
Ah, yes. I had looked for references to PSK, and didn't see them. I didn't
look for text saying "only certificates."
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
I would avoid having multiple EAP types. That would bloat implementations.
It's better to just let implementors / admins configure TLS parameters for one
EAP type, instead of multiple EAP types.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
http
rname (e.g. YmVuZGVy@realm) are allowed. Note
> that the NAI MUST be a UTF-8 string as defined by the grammar in
> Section 2.2 of [RFC7542].
That looks good, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
and Long Certificate
> Chains in TLS-based EAP Methods
This addresses all of my concerns, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
tion will be
impossible.
Perhaps suggest EAP implementations use an upper limit of 100. And then
explain that the limit should not be exceeded, either in practice, or in future
standards.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Jan 20, 2020, at 11:51 AM, Ryan Sleevi wrote:
> On Mon, Jan 20, 2020 at 11:19 AM Alan DeKok wrote:
> The distinction doesn't even matter in the content of root stores. The
> vendor downloads N root CAs, and places them into files / DBs in the product.
> Whether those fil
d manually, then that step is no
different than what we have today. Which means that this intermediate step
further has near-zero benefits.
That's why I'm focussed on the end goal: updating the root CAs *and*
supplicant implementations at the same time. And, making sure that all of
these updates ship with t
On Jan 20, 2020, at 11:19 AM, Alan DeKok wrote:
>
> Any "supplicant division" of an OS vendor will require high-level signify
> before massively changing user workflow. So in the end, it *is* the "OS
> vendor" who has to be convinced.
Please read "
if
> the end user experience is "it just works"
When I do RADIUS stuff, I say "the vendor has to do X". It's never been
useful to say "Bob in engineering department X has to do it". The distinction
you're making is 100% irrelevant.
If this distinction is necessary and im
with fewer steps. It still requires extra software /
configuration / whatever to be downloaded. And that's the situation I'm trying
to avoid.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
301 - 400 of 655 matches
Mail list logo
