support resumption, 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.
__
checked
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
really whether or not 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
.
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
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
gt; route. It 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 propert
c5216#section-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
use an experimental type, it doesn't matter 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 int
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
ajor difference from
TLS 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
ically suggested it,
> I suspect that allocation 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
flight.
Except that if 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
7;re done".
If the client cert has issues, the server can send 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
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 requir
ies provide 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
ht
On Feb 1, 2021, at 2:32 PM, Joseph Salowey wrote:
>
>
>
> On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok wrote:
> 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 &
LS 1.3, the exporter 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
otify doesn’t allow 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.
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.
___
ce as 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
om the draft. 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
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
of
the draft is to publish a clear, secure, 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
e pros and cons of it's choices, then the draft
should be updated 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
e machine, nor can we depend upon 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
e
verifying the 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
tml
...
When post-handshake authentication occurs, 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
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.
_
ld impose no additional burden on
implementations/
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
h, 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
gest 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
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" discar
very useful for a specification 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
and close_notify are
encrypted by the TLS layer, and therefore meet the security and privacy
requirements of altAccept and altReject of RFC 4137.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
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
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 neg
may be tied to a WiFi SSID.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
rror.
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
s by 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
nd a TLS alert. After rooting through OpenSSL 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
er
tunnel, as 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 ne
will only sign certs which
contain a very limited 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
On Feb 18, 2021, at 10:38 AM, Alan DeKok wrote:
> Implementations largely fixed that years ago via a few methods:
>
> * on initial connection to SSID, prompting the user to see if the certificate
> is OK (historical, and less permitted these days)
>
> * pre-provisioning SSI
r own thing, because the specifications are lacking. Worse, the
processes used by standards bodies are lacking.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
nt?
Yes.
> c. Did you run into any issues with this mechanism?
No.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
RFCs have historically been silent on choosing encryption methods,
digests, etc. Yet there are any number of RFCs which describe an application
using TLS, and which give guidance as to which encryption methods are mandatory
to support. I can think of 3 just for RADIUS.
&
On Feb 19, 2021, at 11:14 AM, Joseph Salowey wrote:
>
> On Fri, Feb 19, 2021 at 3:32 AM Alan DeKok wrote:
> On Feb 19, 2021, at 12:26 AM, Joseph Salowey wrote:
> > I'd like to hear from implementers about their experience with this
> > mechanism:
> >
&g
nternet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the EAP Method Update WG of the IETF.
>
>Title : TLS-based EAP types and TLS 1.3
>Author : Alan DeKok
> Filename: draft-i
I'd like to apologize to John for mis-stating what he said. That attempt at
paraphrasing his comments was wrong.
I will summarize any technical issues I have in a separate thread.
Alan DeKok
___
Emu mailing list
Emu@ietf.org
his thread if you disagree.
Mixing the type-code in the label is more complex to implement than simply
using it in the context. As such, I prefer to use it in the context.
Such use falls well within the examples given in RFC 5705.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ype-code as the context, and use a constant label across EAP types
There appears to be consensus among implementors that (2) is preferred.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Section 1 says:
This document defines how to use EAP-TLS with TLS 1.3 (or higher) and
This text is incorrect.
Q: Does this document define how to use EAP-TLS with TLS 1.4? What if
TLS 1.4 changes the TLS layer in such a way that EAP-TLS requires
modification, as done with TLS 1.2 to TLS 1.3
Summary:
The document says it defines EAP-TLS with TLS 1.3 (or higher). This
is not true, and all references to "or higher" should be removed.
It allows for multiple session tickets, going against the
recommendations of RFC 8446, and against the consensus from
implementors.
It implicitly perm
There has been previous discusson about the number of session tickets.
This discussion needs to be revisited, as the request to update the
document was rejected for erroneous reasons.
RFC 8446 Section C.4 gives guidance on this exact issue: How many
session tickets should be used for an applicati
submit a PR to update the document.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
"@realm"
as a short-hand for the realm. But also that single-label realm names are
forbidden by RFC 7542 Section 2.2.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
no response (other than Bernard's short note) to the detailed
review I posted to the list. On looking at the draft, none of the issues seem
to be addressed.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
trips is to work around issues where the EAP peer and
server ended up in an infinite loop ACKing their messages. ...
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ong. And, we know @realm works, because it's
already been working with EAP for a decade.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
don't know why you'd use it. But if someone else does use it, and
it works, great. Otherwise, buyer beware".
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
al thing you can depend on
is the CA. If the CA is trusted, nothing else matters. If the CA is not
trusted, then nothing else matters.
i.e. for any kind of increased security you'd like to add to EAP-TLS, you can
almost always find a scenario where that security forbids real-world use-c
endent of the previous one, and may be overly
> broad. Let me give you an example: a device may be designed only to operate
> as part of a federation.
I would agure there that the federation should have it's own CA.
I'm not sure what it means to have a fede
nt could tell the difference between the "fake" server cert, and a
real one.
As a result, it looks like id-kp-eapOverLAN is not appropriate for server
certs.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
organizations control (public CAs)
Only if the peer doesn't notice if the server cert changes.
I think it's safe to recommend that clients pin both the server cert and the
CA cert. Anything else is "there be dragons".
Alan DeKok.
Given the time frame for the EAP-TLS document, I suspect it's best to just
say "here be dragons", and leave it at that. Any attempt to define new
behavior may be time consuming.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
d a key
> update message so an implementation detecting the reception of a keyUpdate
> message MAY process or ignore the message since only a minimum amount of
> application data is exchanged in the channel."
That's great, thanks.
Alan DeKok.
upplicants would show the
entire cert to the user. Now, many don't even do that. Some just show a
fingerprint in a pop-up dialog, and ask the user "is this OK?".
How that's useful to anyone is beyond me.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
; At least requiring an EAP-specific EKU or OID would require operating systems
> to separate out the EAP trust store.
I agree 100% there.
> TLS Web Server Certificate should not be acceptable for EAP.
Well, yes. The question is how do we g
servers
> for TLS 1.3, I think the time is appropriate for making the server
> certificate requirements more strict. This is likely the last chance for a
> long time.
I strongly suspect that there's no consensus here, and this really isn't the
document to
> On May 5, 2021, at 11:33 AM, Joseph Salowey wrote:
>
> This is the working group last-call for draft-ietf-emu-eap-tls13. Please
> review the draft, focus on the recent changes and submit your comments to the
> list by May 20, 2021.
Section 1 says:
While this document updates EAP-T
ugh consensus and running code" means I
should be able to say the following, and be taken seriously:
"Hi, as someone with running code, I believe that it is critical for the
specification to say X, in order to address implementation and inte
ived
in the EAP-TLS application, by passing EAP-TLS parameters to TLS key exporters.
So the TLS layer has no concept of what MSK or EMSK are. As a result, the
TLS layer should have minimal input into what those keys are, or how they are
derived.
Alan DeKok.
___
secure. Perhaps we should
> remove the TOFU mechanism text or state that it does not work well in all HA
> configurations (where different servers use different certificates)
Perhaps just state that it does not work well in HA configurations.
I don't think TOFU can be secure
or not to revert
> some of the text in the key derivation section. If you object to the change
> please state why. Please respond by May 20,2021.
We should revert to the -13 key derivations.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
... and one or more server names ...
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
uthentication is not used, deployments
>MUST take care that the resulting access granted by AAA servers and
> network authenticators is appropriate for
>unauthenticated peers."
Yes.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
wed by a suffix which is one of
the trusted server names.
I think it's past the time where this document can ask supplicants to change
their behavior. We know what the supplicants do, it's not wrong, and it seems
to work. So let's document that, and move on.
Alan DeKok.
not allow for
>the server certificate to change without out-of-band validation of
>the certificate and is therefore not suitable for many deployments
>including ones where multiple EAP servers are deployed for high
>availability.
>
>
> On Thu, May 20, 2021 at 1
Some comments have been addressed, others not. The majority of the issues
raised in my review have been silently ignored. Some issues are nits, some
affect interoperability and security.
Until these issues are addressed, the document is insufficient to guide a
reader into creating a secur
On Jun 11, 2021, at 9:08 AM, Mohit Sethi M
wrote:
>
> Hi Chair/AD/EMU:
>
> We have submitted a new version of draft-ietf-emu-eap-tls13 based on the
> extensive feedback from Alan Dekok, Heikki Vatiainen, and Oleg Pekar.
>
> Can we somehow prioritize this document and
implementations, then it would be useful to address comments from major
implementors.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
n't expect to get that particular response. It is distinctly
unusual.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
e should add?
I am wary of repeating text about negotiation, which might be inconsistent
with the parent reference. The text isn't wrong, but it may be worth just
saying something to the effect of "EAP-TLS does not do cryptographic
negotiation,
EAP peers. As such, we
> believe that this section contains minimal new interoperability or
> implementation requirements on EAP peers.
>
> [Joe] This does not seem to add to the specification.
I agree that text doesn't add any new requirements to the specification.
However, it's useful to make a note for implementors that while Section 2.2. is
officially a new requirement in theory, there is little to do in practice,
because implementations already meet these requirements. There has been
similar text in many other specifications.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Are there any other remaining issues that are not listed on GitHub?
My review of a few days ago had extensive comments. It may be worth going
through that and addressing each issue. Some of the items have been addressed,
which is positive. However, it looks like all of my comments for Sec
tls13/issues/84) to track this.
>
Thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
st just deleting "While certificates
> may have long validity periods,". There is already text describing that
> certificates can have very short lifetimes.
Sure, that works.
The rest of the changes look good, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
gt;* EXPORTER: Session Key Generating Function * EXPORTER: Extended
>Session Key Generating Function * teapbind...@ietf.org”
Fixed, thanks.
> - The draft mentions “commitment message” several times, but you are probably
> aware of that.
Yes. Now that eap-tls13 no longer uses that, I'll update this draft to be in
agreement with it.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/86
I didn't see anything on cross-protocol use of certs.
i.e. Section 2.2 suggests that the certs contain an FQDN. But it's likely
bad practice to allow the same cert to be used for EAP, and for WWW.
There's some suggested text fo
: TLS-based EAP types and TLS 1.3
>Author : Alan DeKok
> Filename: draft-ietf-emu-tls-eap-types-03.txt
> Pages : 15
> Date: 2021-06-22
>
> Abstract:
> EAP-TLS [RFC5216] is being updated for TLS 1.3 in [EAPTLS]. Many
On Jun 24, 2021, at 8:11 PM, Joseph Salowey wrote:
> Actually, PR#83 removes the MAY that makes the authorization behavior on
> resumption optional. Do you still think we need to add this text to section
> 5.7?
No, we can leave it as-is.
A
l MAC, and not the public /
randomized MAC?
I've seen this problem more and more in customer deployments. It's becoming
a serious security issue.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
net
> SSIDs?
Not that I know of.
> About usage of physical MAC address - maybe some client systems will not have
> access to the physical MAC rather than just to a randomized MAC.
That is true. My goal here is not to make things perfect, but to be able to
manage a device, when tha
ar 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.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
endors randomly change APIs, UIs, and workflows. It's all a horrible bodge
which is productive for no one.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
y.
> 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.
That's good, but I suspect it will
TPM-%3A-A-New-Authentication-Protocol-for-IEEE-.-Latze/6d755cf4d1ac1da25c8d02a2e5cba56212149d69
So we've had this capability for a decade. But no one has found time /
interest in moving forward with it. This makes me think that TPM is not really
the best choice here.
Alan DeKok.
__
blem which remains unsolved.
TEAP is one solution, but I don't think everyone is going to move to TEAP
overnight. It would be nice to have solutions for existing (and deployed) EAP
methods.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Jul 1, 2021, at 10:08 AM, Eliot Lear wrote:
>
> On 01.07.21 15:23, Alan DeKok wrote:
>> TEAP is one solution, but I don't think everyone is going to move to TEAP
>> overnight. It would be nice to have solutions for existing (and deployed)
>> EAP methods.
>
, instead of having them pay me to paper over issues in
multiple products.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
401 - 500 of 800 matches
Mail list logo
