sy to update Open Source
supplicants to check new OIDs. The larger vendors might upgrade. Eventually.
Maybe.
On a technical front, a major issue is also *how* to upgrade. What do
supplicants do? Allow both OIDs? When do they start rejecting certificates
with the "TLS web server"
On Nov 16, 2019, at 7:59 AM, Owen Friel (ofriel) wrote:
> [ofriel] this seems like something reasonable, but that's more a general
> deployment recommendation: ensure that the identity/realm of EAP servers is
> different from the identity/domain of webservers within an org. Therefore in
> the a
the
user, then the user should be warned, and the certificate rejected.
If accepted, I think that such practices would tremendously simplify the use
of TLS-based EAP methods for both users and administrators.
Alan DeKok.
___
Emu mailing list
Emu@ie
n names. We can *suggest* that
supplicants can check these fields. But it involves parsing them, and deriving
*implicit* meaning from them.
In contrast, an NAIRealm field is *explicit* meaning, that doesn't require
additional derivation.
I think that explicit statements of intent a
and defend it. Attacking a straw man version of
someone else's position is unhelpful.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
evious messages for explanations.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Nov 18, 2019, at 11:01 AM, Cappalli, Tim (Aruba) wrote:
>
> So you’re saying an NAIRealm must be a publicly registered domain name? I
> agree, but just want to be crystal clear.
Yes. See RFC 7542. It defines the NAI in some detail.
A
On Nov 18, 2019, at 6:22 PM, Dan Harkins wrote:
>
> On 11/12/19 3:40 PM, 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 telep
hat the certificate owner has claimed he can
be reached at that number. And the CA has signed the statement, agreeing that
it's a statement made by the certificate owner.
>> These issues can't be answered with simple black & white statements. If
>> the data in a certificate is imperfect, it might still be useful.
>
> OK, convince me of its utility.
See RFC 4334 and its discussion of SSIDs.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ther or not to accept the
cert.
> This attribute seems useless to me and its ambiguity and therefore
> unverifiability is a
> large reason why.
I would suggest not using it for your own purposes then. I would also
suggest allowing *others* to use it, if they find it useful.
Al
adopts this practice, then it can be used by
millions, if not tens of millions of people. And making EAP easier to use is
always of enormous utility.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
explanations. You reject them
whole-sale, and keep asking me for more explanations.
> I'm not proposing to prevent you from doing anything. I'm asking what's the
> point
> and why. You didn't really provide one. And good
On Nov 21, 2019, at 7:39 PM, Dan Harkins wrote:
> I think we have made progress and closure.
No.
The word "unverifiable" is not a magic wan that you can use to win any
argument.
Your description of what I'm proposing does not match what I'm actually
p
CA.
> In my mind, this is no different from organizations that want TLS
> certificates for their servers named “webmail” (not globally unique) or
> “mail_01.company.example” (not preferred name form / LDH). The answer is “use
> private CAs, don’t use public CAs”
I agree.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
is
>> a migration challenge, and clients cannot make a hard check for these values
>> against all public CAs. This doesn’t really seem practical in the near term
>> at all.
>
> Trust NAIRealm extension only if id-kp-eapOverLAN is set.
> having impleme
ve a separate section about identities. I find the
current text a bit unclear. It helps to explain why an anonymized NAI is
useful, even when there is no email address in a certificate.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ve the anonymous NAIs should
always be used. The only situation where they're not necessary is where the
authentication is known to be site-local. i.e. the EAP supplicant and
authenticator are both in the same network.
In all other situations, there is no down-side to using anon
to me where the correct forum is to even document these
> recommendations, or who needs to be involved.
The Wi-Fi alliance is already moving ahead with a similar approach.
https://www.wi-fi.org/download.php?file=/sites/default/files/private/WPA3_Specification_v2.0.pdf
See Section
nt root store.
i.e. implementations default to not trusting CAs for EAP. The trust has to
be explicitly enabled by an admin, or by the user. This means that there's a
store of CAs *only* for EAP.
Everyone knows that it's wrong to use id-kp-serverAuth for EAP. The way
forward is to figure out how to fix it.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
or
> how that's phased out. But explicitly moving towards that goal, and not
> trying to live in the interim with id-kp-serverAuth, seems the best path
> forward.
I welcome concrete proposals to move forward. The discussion here seems to
recommend against using id-kp-eapOverLAN and NAIRealm. Which means we *don't*
have a way forward.
In the absence of a solution, it's best to document existing practice.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
version and we will send this forward to the IESG.
> To expedite the process, let me already ask the following :
Done.
> Can you confirm if all appropriate IPR disclosures required for full
> conformance with the provisions of BCP 78 and BCP 79 have already been
> filed for d
e a way forward until WG consensus is reached. Which is why
we're having this discussion.
Honestly, I'm confused at the discussion here. You're not showing any
*concrete* security issues above what I've already discussed. You're not
proposing anything better. You're claiming that EAP doesn't work today. You
want to fix things by breaking everything.
That's... not something I understand.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ve to deploy the new behaviour has been discussed
here: ease of configuration of the end-user devices.
Other SDOs like the Wi-Fi alliance are moving ahead with their own
requirements on certificates. CAs will support those requirements for the
simple reason that it makes them money.
> Hopefully that's easier to understand. I'm not sure how we ended up on such
> different pages, but I think the assertions and requests from your last
> message were a good indicator that we weren't even in the same postal code,
> let alone the same page, as far as discussions go.
I agree. I think some of the disconnect may be addressed here.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
/ Apple / etc.) ship with known
root CAs. These root CAs are trusted by default for web browsing. None are
trusted by default for EAP.
> My issue with Owen’s original proposal, and hopefully it remains clear here:
> overlapping the PKIs should be a non-goal. Distinguishing them at the EKU is
> fine; distinguishing them at the EKU so extant CAs can issue from extant
> trust hierarchies is problematic and should be a non-goal. At the same time,
> changing the EKU in order to change the profile, and having supplicants
> strictly enforce that profile, _is_ a good idea, in as much as it allows you
> to explicitly transition to a sensible and defined profile and make a clean
> break.
That's been my position from the beginning.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
pto
library implements EAP. I suspect that they also have an EAP implementation
which calls a TLS library to do the TLS work.
So I don't really care how OS vendors implement certificate checking for
HTTPS. It doesn't apply to EAP. Bringing up irrelevant issues is just
confusing and unhelpful.
> Right: we're in agreement, I believe? Getting "trusted by default for EAP"
> means disconnecting from id-kp-serverAuth, as part of, well, introducing the
> concept of "trusted by default for EAP".
Yes.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Jan 8, 2020, at 11:29 AM, Ryan Sleevi wrote:
> On Wed, Jan 8, 2020 at 10:38 AM Alan DeKok wrote:
> The rest of the disagreement is (from what I see), bringing up situations
> or use-cases which are unrelated to EAP, and therefore confusing the issue.
>
> They're rel
On Jan 8, 2020, at 3:00 PM, Michael Richardson wrote:
>
>
> 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 ro
the root CA.
This lets them warn the user if the server certificate changes.
But this process also means that the user is warned on normal certificate
expiration / replacement. There is currently no guidance to implementations as
to what should be done here.
Alan DeKok.
_
IER ::= {id-kp 1}
-- TLS Web server authentication
new ID: delete the word "Web".
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
That is likely the best approach. At this point, use of id-kp-serverAuth is
wide-spread *outside* of HTTP. EAP / RADIUS is not unique in it's mis-use of
that OID.
As such, this discussion should more productively focussed on non-HTTP
mis-uses of id-kp-serverAuth. Which means pretty mu
is a lot more verification that EAP
supplicants need to do before automatically trusting a root CA.
I suspect that most CAs already know that their customers mis-use certs for
non-WWW purposes. EAP / RADIUS is just a minor (almost insignificant) part of
this problem. I also suspect most CAs operate based on the hope that no one
notices, and then requires them to revoke many, many, certificates.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
at
does that information look like? What's in the certs?
2) a supplicant is unconfigured, how is it possible to get the supplicant to
state (1) above? Is the information available in state (1) helpful for
provisioning?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
the CAs you pointed to are violating their own policies. Therefore, you are
under a moral obligation to report this mis-use to them. Failure to do so is a
tacit admission that you are not applying the rules in practice. While at the
same time, claiming that
On Jan 18, 2020, at 8:55 AM, Ryan Sleevi wrote:
> On Sat, Jan 18, 2020 at 8:05 AM Alan DeKok wrote:
> As noted by Michael, CAs are using certificates in a way that violates
> their own policy.
>
> Um, no. I largely didn’t respond to Michael’s email because it missed the
nchors,
> trusted for this purpose in a default install of my operating system /
> browser / insert X here, and which chains to that public key”. That is, you
> can’t get one of these certs chaining to the same root. Some might, but
> you’re right, that’s much
sy screwdrivers, even
> if they are both “tools one uses when building furniture”
Sure. So how does *my* application get Microsoft, Apple, etc. to ship a new
PKI?
Answer: even Microsoft and Apple can't do it for their own applications.
They just leverage the pre-existing WWW
upplicant is shipped with the OS. Therefore, any root CAs needed
by the supplicant MUST be included with the OS.
It really is that simple.
In conclusion, we need a new PKI, and the root CAs must be included with OS
distributions. But the OS vendors won't do that until we define the
requir
🤷
There have been attempts to simplify supplicant configuration with a standard
XML format. The vendors expressed zero interest. And that's a *lot* easier to
do than adding a new root store.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
With your proposed work flow, this is just impossible. It's really just
manual configuration 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
does not involve shipping roots in
> the OS, but roots in the supplicant that comes with the OS. The distinction
> is quite meaningful for the reasons outlined throughout this thread, even if
> the end user experience is "it just works"
When I do RADIUS stuff, I say "the
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 "
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
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
ips, otherwise authentication 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
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
n encrypted username (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
LS (everything else)
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 maili
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
> 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.
__
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
t 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 whi
gt;> The EAP peer certificate chain does 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.
*talk* about it. Most everyone 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
s of text. 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
e, and how/what do you advise?
> https://www.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
h
means that you are limiting the market 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
roposal? Who will use it? Why?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
gaging 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 publis
> 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
first, second
> 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.
s far. I believe the adjustments
> 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
some 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.
_
interoperability.
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
C 5247 implies a need for the unguessable property.)
Yes. I'll add some text.
> "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
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 clie
S 1.3.
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
gt; 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 "
ent.
> 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
good to add a sentence such as:
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
n practice.
That point is not to be taken lightly. A different set of behaviours may
cause 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
he RADIUS layer
synthesizes an EAP 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
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
x27;s 2020. I'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
ould be nice to remove 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
agrees to 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
ly feels like a worthwhile 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
prising.
> 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 mailin
uot;ad 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 m
In 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
n 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
cument. Leave it in there if someone in the group 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
uld be fine to make OCSP stapling optional.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
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.
__
that 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, n
+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 certif
s security, 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.
___
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
ange made to the new draft 3.
That's a better approach, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
; accounting, and policy decisions are reevaluated based on 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
ethods replaced the 0x0D byte with their 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
at we cannot afford 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
than a
solution which 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
nd hostap both export and use 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
server 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.
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
> EAP_EMSK_LEN);
> Maybe we can live with this. But if exporter is called twice, we should use
> different labels as suggested by Martin?
Yes.
Perhaps as Joe suggested: EXPORTER_EAP_TLS_MSK and EXPORTER_EAP_TLS_EMSK,
which seem simple enough.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
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
ptually, for implementations, 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.
The code 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
en the next question is "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 thinki
301 - 400 of 800 matches
Mail list logo
