his 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.
_
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 know
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 related
sn'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
mains 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
efully 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
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
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 draft-ietf-emu-e
uth, 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
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
re 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 5, page 10
e 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 anonymous NAIs
n 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
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 implemented the dNSNAME code path, it seem
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
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
proposing.
> 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 luck getting a public CA to
> put
> ambiguous and unverifiable information in a certificate for you.
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
t 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.
Alan DeKok.
_
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
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
nd 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
uggest* 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 are useful. I don't see why
t
ser 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@ietf.org
https://www.ietf.o
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
k 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" OIDs?
Alan DeKok.
__
SSID.
i.e. inclusion of an SSID in a certificate is *not* a statement about
"ownership" of that SSID. So your comments seem to be against an issue that
doesn't exist.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
e work?
Do public CAs verify that the OIDs in the certificate match the intended
use-cases?
Is there a global registry of SSIDs which the public CA could use to verify
the SSID?
To put it another way, I'm not sure why this question is being posed.
Alan
S web server auth OID
(1.3.6.1.5.5.7.3.1).
So yes, RFC 4334 is absolutely relevant here.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
d
then download a supplicant configuration. Stefan Winter has a draft:
https://tools.ietf.org/html/draft-winter-opsec-netconfig-metadata-00
But it received little support from vendors.
Security should be simple, and it should be the default. Users don't
, as
nothing checks them.
It would be useful to suggest how a supplicant can use these fields to
further verify a server certificate. And for servers, what these fields should
contain.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
nce
> olong the lines of checking for TLS stack behaviour.
I think it's best to give guidance in this document.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
figuration file that creates certificates with the NAIRealm is
located here:
https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/certs/server.cnf
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
OIDs.
On the other hand, RCC 7585 uses the OID for TLS connections which then carry
RADIUS packets. This draft would use an OID for EAP-TLS authentications, which
are carried inside of RADIUS, and then inside of UDP / TCP / TLS / DTLS. The
uses-cases may be differ
ul to
describe the impact of that. What does an implementation do? How should
administrators tell PSK identities apart? If the EAP authenticator can't
control the derivation of PSK identities for resumption, is it even possible to
have manually provisioned PSKs?
Alan DeKok.
_
ly
best to move the TLS 1.3 fixes into a general "oops, we need to fix TEAP"
document.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
server
> implementation from supporting extern PSK by disallowing it in the spec. If a
> particular EAP server does not want to support extern PSK - that’s fine.
Then we need to give guidance on what implementors and administrators should
do. Even if it means adding text saying &
eer. 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.
After checking the draft again, Section 2.1.4 does have comments about
anonymizing the NAI. But those comments are limited to NAIs derived from
certificates.
I think that the text needs to be expanded to make the recommendations more
genetic, and clearer. I hope that my previous message
On Nov 1, 2019, at 7:53 AM, Eliot Lear wrote:
>
>> The EAP Identity used in resumption SHOULD be the same EAP Identity as was
>> used during the original authentication. This requirement allows EAP packets
>> to be routable through an AAA infrastructure to the same destination as the
>>
derlying TLS
implementation, and cannot be controlled by the EAP authenticator. These
limitations make the PSK identity unsuitable for use as the EAP Identity.
---
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t only look bad, it will *be* bad. And the industry press will
(rightfully) lambast the standards process.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
I will, and I think it's a good idea.
> Is there any objection to move forward with making the MAC variable length?
No.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
e updated so that
we can create inter-operable versions.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
AST and TEAP from
draft-dekok-emu-tls-eap-types, as the remaining items are not controversial.
The document should then be published simultaneously with the EAP-TLS updates.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
it. That
for me is a strong reason to forbid it.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
think we
should take into account what people *do* with EAP methods.
In this case, people have voted with their feet. EAP-PWD, PEAP, and EAP-TTLS
are widely deployed. They all support some form of name / password
authentication. PEAP and EAP-TTLS also include support for anonymous outer
ide
use that's ever so much easier
than using nasty certs.
That isn't something we should encourage. It may be worth just forbidding it.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
I don't see why this would be more of a problem in EAP-TLS with TLS 1.3 that
> in any other application of EAP-TLS.
I agree.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
resumption. It should reference RFC 8446 Section 8.1, and 8.2, which discuss
this issue. Also, Section 4.2.11 of that document has an "Implementor's note:"
which is important.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
user" PSK in the DB.
Simply waving your hands and saying it "uses" a field is unhelpful. Please
give substantive feedback and/or advice about what the code *does*.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
if it has some significant
> advantages over EAP-PWD, and there are people wanting to implement and use
> it. 3GPP is e.g. adding identity protection and perfect forward secrecy to
> EAP-AKA instead.
I would prefer to forbid PSK in EAP-TLS.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
s before TLS 1.3 was standardized.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
lways* apply authorization policies. The alternative
is to allow the server to *not* check authorization policies during resumption.
Which then means that the client is in charge of authorization, not the server.
Alan DeKok.
___
Emu mailing list
will have the same issue,
when resumption is used.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
any existing
EMU document would be appropriate for these changes.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
session ticket to
> be sent out is a way to work around this, but I'm not sure I'd call this
> ideal.
I think that's the only practical solution.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
n, any data received should be ignored
* non-zero octets, or more than one octet MAY indicate future extensions
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
; informational document in the working group is preferable to the independent
> submission track.
Yes.
> Do working group members still have objections to taking this draft into the
> working group? Please respond on this thread by July 5, 2019.
I have misgivings, but no o
Which is for TLS 1.2 and below.
> Do you plan to update this for TLS 1.3 and use TLS-Exporter in your other
> draft: draft-dekok-emu-tls-eap-types? Do we need to do this twice in
> separate drafts?
draft-dekok-emu-tls-eap-types already updates the Session-ID for all
TLS-based EAP ty
bug in the original RFCs.
There have been minimal comments on the document. What comments have been
received are supportive.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
when the devices
already work.
I'm not sure what the disagreement is here. I'm saying that the practical
limits are ~50 round trips, and maybe ~64K certificate chains. You're not
disagreeing, but you're asking me to justify my position, and are arguing
against it. I'm not clear what point you're trying to make.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ight not. I've seen standards take 10+
years to *start* getting adopted.
Allowing more packets wouldn't generally increase latency, because
99.% of authentications won't need more packets.
And realistically, if you can't authenticate someone after exchanging 50K of
data, you're likely
A million dollars for a 5G operator / vendor? How
much should an Open Source implementation pay?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
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?
Alan DeKok.
___
Emu mai
ompanies can have internal groups at odds with each other.
> Finally, I want to point to: https://lwn.net/Articles/780078/
It may take $1M to get to the point where such legal arguments matter. That
rules out such a defence for me.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
cating via EAP-TLS,
and then using that TLS data to "resume" an HTTPS connection.
That may be surprising to people.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
xtended EAP types.
TBH, the simple approach is to extend the definition of Type-Code when
extended types are used.
Type-Code = 0x0d
for types < 254
Type-Code = 0xFE || Vendor-Id || Vendor-Type
for extended types
And then use that definition for Key_Material, Method-
t the L bit set."
>
> I'm for the strict approach. Anyway some implementations don't adhere it. The
> sentence above narrows the behaviour to a non-ambiguous while requires to
> support all kinds of existing behaviours thus it looks like the most exact
> form
On Mar 11, 2019, at 12:52 PM, John Mattsson wrote:
> There seems to be agreement on the list to add security considerations on
> authorization and resumption. With the text from Alan as a basis (thanks
> again Alan!), I have added the sections below to draft-ietf-emu-eap-tls13.
>
> Some high
dditional information.
i.e. the credentials from the original authentication.
As such, this document needs to give guidance on this topic.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t neither RFC 5216 nor this document gives any guidance here.
They don't even mention checking cached authentication data.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
The previous EAP-TLS spec was written largely to describe EAP-TLS and nothing
more. Realistically, EAP-TLS is almost always used inside of a larger
ecosystem. It is therefore also prudent to discuss how these systems can
interact, and what security issues may arise from this interactions.
ched data described
> above'
Perhaps.
> Took a couple of readings to understand exactly what you meant there.
It's a difficult subject to explain properly.
> The cached data isn't being updated, but it's being used together with the
> unauthenticated
> information, ri
ks like EAP-TEAP-BRSKI requires a similar NAI for provisioning. So it
would best best to coordinate both the name, and the use of it. Perhaps
"provisioning.arpa" could be used as a generic name, and then subdomains within
that could be used for pa
Here's my $0.02 on updates to the "Security Considerations" section.
---
5.9. Authorization
We note that EAP-TLS may be encapsulated in other protocols, such as
PPP [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA
[RFC5191]. Systems implementing those protocols can make
d information is expected and non is available, resumption
> MUST be rejected. For the majority of cases the security policies applied to
> the different TLS based EAP methods will be identical.
Yes, that has to happen, too.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
HOULD be rejected.
I don't understand why there's so little concern about people being able to
PWN your network. It's a disaster.
We can't just paper over this issue. It's a major security flaw that's
designed into the protocol. It needs to be addressed.
Alan DeKok.
___
tocol is open to a large
number of time of use, time of check" security bugs which could cause serious
breaches of networks.
We can't paper over security issues by saying "it's not session resumption,
it's a new session". Well, whateve
This can be
done by caching user identity, policy, and anything else that is relevant.
The draft doesn't say much about these topics, which I think should be
addressed. The issue of "auth with TTLS and resume with TLS" is just a tiny
part of the iceberg.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
tocol.
These issues need to be discussed in a lot more detail before the problem
statement, and solution, are clear.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ngth" field.
> Looking forward to some great guidance and advice :D Also, if you would like
> to collaborate/contribute, please let me know!
I've been known to have opinions. :) Plus, it's useful to have credential
provisioning methods.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
This is a first draft, and is very rough. I've done things which make sense
to me. But, for FAST and TEAP, I have no idea. Reviews / comments / etc. are
welcome.
Alan DeKok.
> Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: New Version Notificati
at the peer is unauthenticated. With this
> functionality in place, I do not see that resumption as such is the problem.
I agree.
> I think draft-ietf-emu-eap-tls13 needs some sentence about the peer can use
> specific NAIs to affect the server's behaviour. Emergency services being
eers
> and servers MUST comply with the compliance requirements (cipher suites,
> signature algorithms, key exchange algorithms, extensions, etc.) for the TLS
> version used. For TLS 1.3 the compliance requirements are defined in Section
> 9 of [RFC8446]."
Looks good, thanks.
A
changing octet 5 of the EAP packet changes any of the
security properties. And the explanations so far don't address any of my
questions about this topic.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
cated status of a session, and refuse to resume a session when
authentication had not completed.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
er TLS-based
methods are updated. I've tried to be clear on that. We can publish EAP-TLS
updates quickly.
I'm saying that the second document needs to be published nearly
simultaneously with the EAP-TLS document.
Since that document is small and hopefully not contentious, this s
an issue with cross-method session resumption. I'm happy to
allow it. I was pretty clear on that.
What I'm saying is that if there's no consensus that it should be allowed,
then I'm fine with forbidding it.
Alan DeKok.
___
Emu mailing list
Emu@ie
packet.
Saying "security properties" when only octet 5 has changed isn't a convincing
argument.
Maybe the answer here is "we have no idea what cross-method session
resumption means, and therefore we forbid it".
That's a good answer. But if there are rea
e
others is a major problem IMHO.
> Anyhow, I don't expect the other document to take 18 months. I look
> forward to your submission (and reviewing it once it is available).
It should be small. And the WG should be incentivized to publish it quickly
authenticating with certificates.
Other TLS-based EAP methods allow the use of client certificates, too. While
not the normal use-case, it is a well-known and deployed use-case.
The document should add a note that the issue is less of a concern when
client certificates are not used
s, the customers *will*
demand one, and implementors *will* create one. At that point, the IETF will
have ceded change control for those EAP methods over to those implementors.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
to understand the reasons behind doing it.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ntication. If the EAP server needs to
do additional *authorization*, it can always refuse to resume the session.
But if there's no additional authorization, I don't see any issue here.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
de-spread use in multiple PEAP"
>
> Should remove ")." and add a blank line.
Fixed, thanks.
I'll do some more touchups and issue a new draft next week.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
uch as TTLS / FAST
> / PEAP / TEAP as well. The only thing that would change is "EAP-TLS" replaced
> with " TLS-based EAP Methods" in a number of places. All the technical
> content would be the same.
I think that's good, thanks.
Alan DeKok.
er-tunnel authentication.
In contrast, FAST and TEAP both still require phase2 to occur after session
resumption. The session resumption there is just used to skip the TLS
negotiation. And the MSK / EMSK depends on the inner tunnel authentication
methods, so the TLS-Exporter() function needs mo
ually done at the TLS layer. This means there is minimal ability for the EAP
layer to cross-check method types.
If we do allow it, it should be called out explicitly in the EAP-TLS
document. If we don't allow it, we should find a way to forbid it.
andshake,
but then application data shouldn't be protected by TLS?
That doesn't make sense...
I'll also note that RC 5216 Section 2.4 mentions mandatory to implement
ciphers, and this draft doesn't. It might be worth adding that, or adding a
note referencing an
401 - 500 of 645 matches
Mail list logo
