her implementations.
We're working on implementing this in FreeRADIUS.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
quot;bootstrapping"
once, and "provisioning" many times.
My $0.02 is that "provisioning" is clearer in this context than
"bootstrapping".
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
specific claims of the
> application...
I share these concerns.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
of implementations and inter-operability, I would
oppose yet another point of negotiation. It does not add anything IMHO. And,
it makes implementations and inter-operability more complex.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
is, we should tell the TLS working group that we are
> planning this and ask for their view.
My larger worry is that underlying SSL implementations may not support
caching of certs from dropped handshakes. It may be hard to add features to
SSL libraries which are used only by EAP-TLS.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
nt does not support it, which makes it inapplicable here.
Never the less, something similar could be done with User-Name in the
Access-Accept. And, it should be supported by all enterprise equipment.
It may be useful to discuss these topics in a "best practices" document for
E
to have a wider "fan out" of certificate dependencies, instead of a deeper
chain of certs.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
can be different, and
reference Section 4.2 of RFC 7542.
For an implementation of inner/outer identity checks, see:
https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/policy.d/filter#L111
It's not perfect, but it seems to work well in practice.
Alan DeKok.
_
t;MAC-ADDRESS@anonymous.realm". in order to separate the namespaces
of "real" identities, and "anonymized" identities.
Comments?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t help reduce your concerns?
It suggests that the risk may be low. But the risk is there.
TBH, there's no good solution for this situation. It's needed, but at the
same time anyone using it is opening themselves to lawsuits that they can't
afford to defend, much less lose.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
f
the standard space. And we rely only on their good will for continued use of
an open standard. That tends to make me nervous.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Before you can progress away from that
> and the RFC 5448-only modes, much time will pass.
I've been doing my thing for 20 years. I'm not going anywhere, so I'm
thinking about the long term.
Anyways, I think this is necessary.
Alan DeKok.
__
there isn't much that can be done here
In the end, I think any information we could use is already being used to
derive TLS-Exporter, and there's no real way to get additional information.
And even if there was, it's not clear what information would make the
TLS-Exporter "
that output. Failure to do so will result in incorrect
values being calculated for the above keying material.
--
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
EAP-AKA’. The lack of this definition
is a recently discovered bug in the original RFCs.
I owe the WG a document for that. If the above change isn't accepted, I can
add some text on TLS 1.3 key derivation, too. The document could then be a
generic "fix keys in EAP methods&qu
with text that says:
MSK = Key_Material(0,63)
EMSK = Key_Material(64,127)
It's not any more text, and it removes a potential confusion.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
hod_Types that are
larger than 255 SHOULD use Method_Type as a 32-bit number in network byte order.
---
Without such text, there will be problems. People will want to use TLS 1.3
with other EAP methods. And if there is no standards guidance, the
implementors *will* choose something, so that me
derived in the same manner as
with EAP-TLS [RFC5216], Section 2.3. The definitions are repeated below for
simplicity:
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ods. I have a strong
preference that *all* TLS-based EAP methods be capable of working with TLS 1.3.
Maybe this document isn't the place for these updates. But IMHO, any updates
to TTLS, FAST, etc. MUST be published simultaneously with this spec. Otherwise
implementors will have no guidel
The EMU charter says:
- Define session identifiers for fast re-authentication for
EAP-SIM, EAP-AKA, and EAP-AKA’. The lack of this definition
is a recently discovered bug in the original RFCs.
I have recently uploaded a document which addresses this point.
https://datatracker.ietf.org/doc/dr
discussion of other EAP methods is outside of the scope of this
document.
---
That way there's at least *some* guidance. Any additional discussion (and
there may be lots) could go into another document.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
n 7.3
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Jan 31, 2019, at 11:55 AM, John Mattsson wrote:
>
>> Alan DeKok ; wrote:
>>
>> Hmm... if the changes are too complex, it may be better to have a new
>> document. I have a first draft written, and will be publishing it soon.
>> It's only about 12 page
e the handshake,
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
ption is
usually 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 w
ner-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 nee
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.
___
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
to skip inner authentication. 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
y to do that, I'd just like to understand the reasons behind doing it.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
her methods, 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
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
ng the
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
e while changing octet 5 of the EAP 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".
Tha
t* what I said.
I don't see 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.
LS document until the other 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 an
henticated 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
how 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
EAP-TLS peers
> 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, th
he fact that 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
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 Notif
se the EAP header
has a 16-bit "Length" 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
solve, and may avoid the need for yet another protocol.
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
rent* policy for the session resumption. 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
And it means that the protocol 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&#x
he resumption SHOULD 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
argue if cached 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
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 polic
t looks 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 f
maybe 'then it MUST be used in combination with the cached 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 i
nal issues which need addressing.
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 issue
int is that 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
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
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 le
US sets the L bit only if it is sending
fragments.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
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
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 from authenticating 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
talks to the engineering group. Large
companies 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
7;s only hostap and FreeRADIUS. On the client side, it's hostap.
There used to be "xsupplicant" and "open1x" on the client side, but those
have been dead for 10 years.
> In particular, the use of the
Early truncation?
Alan DeKok.
__
*what* is that fee? 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
rd is published. Or it might 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
ve
the time, budget, or inclination to upgrade our replace them 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
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
erver.random).
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
T
; 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
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
ries. Forcing a new 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
x27;m not sure that 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
e TLS wg document draft-ietf-tls-oldversions-deprecate (Submitted to IESG
> for Publication) formally prohibits negotiation and use of TLS 1.0
> and TLS 1.1. It also updates all RFCs that use TLS.
I suppose so. I do suspect, tho, that there are million
hods will have the same issue,
when resumption is used.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
to *always* 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
s before TLS 1.3 was standardized.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
should only be done 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
real "end-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
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
PSK identity.
> 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
sswords for EAP-TLS with PSK. Because 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
ocess. I 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
eople will abuse 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
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
to be updated so that
we can create inter-operable versions.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
on?
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
'ing TTLS and PEAP,
it will not 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
ing 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
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
>> origin
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 c
no mechanism to return an error code to the peer. How could we
> signal in EAP the error difference between routing vs EAP method unsupported
> failures? Or can we at all?
EAP provides for a NAK for negotiation, and a Notification packet for
signalling errors or messages. Unfortunately,
t preclude a specific EAP 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 m
ch, it's probably
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
very useful 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.
eful to have two separate
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
a configuration 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
d to use"?
I don't think so.
> And the "EAP provides for method negotiation" is via Nak messages, Ok, then
> my confusion was on the EAP method selection statement in section 5.1.
EAP is unfortunately complex.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ed to document guidance
> 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
these names, 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
TPS secured web site for example.com, and
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
ire the TLS 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
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.
ontains no text about "ownership" of the 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
201 - 300 of 800 matches
Mail list logo
