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 pages, bu
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
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
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.
g
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 guidelines, and TTLS / FAST / P
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
r 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 meet real-world demand.
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
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" document.
rrect
values being calculated for the above keying material.
--
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
one 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 "better". Or even what "better"
e UE. 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.
_
rd 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
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
ous.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
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.
___
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
hich 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
EAP and user anonymity. I
king 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
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
specific claims of the
> application...
I share these concerns.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t;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
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
I will review it.
> On May 28, 2018, at 4:58 PM, Joseph Salowey wrote:
>
> I didn't see any objections, but I want to make sure we have some folks
> willing to review the draft. Please respond to this thread if you would be
> willing to review the draft.
>
> Thanks,
>
> Joe
>
> On Sun,
large as possible.
That gets you a rough upper limit on the size of the certificate.
Even the sample certificates I use for FreeRADIUS testing easily reach 2.5Kb,
with only small amounts of test information in them.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
bjection from you all :-)
That looks good to me. I think it covers all of the open topics of
conversation.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
the
> charter to cover guidance on how to handle large certificates and long
> certificate chains in EAP-TLS with all versions of TLS. This could be handled
> in the same bullet as “guidance or update to enable the use of TLS 1.3”.
That would de
chains. It would be good to find a way to allow this use-case.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
s upgrade to TLS 1.3.
For me, it's 2017. Any proposal that does not address existing deployments
is one that should be ignored, as being out of touch with real-world use-cases.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Can the presenters please send slides to the chairs?
Thanks.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Schaad.
I'll respond with detailed updates in another message.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Alan DeKok wrote:
This is a WG last call on the draft-ietf-emu-eap-tunnel-method
document. Please post reviews, comments, feedback, etc. to this list.
The WG last call will last two weeks, until February 26.
If there have been no substantive comments or issues, we will take
. Minor editorial issues can be resolved then.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Message forwarded from the WG-chairs list.
---BeginMessage---
I sent a message several hours ago requesting that you help and make
your working group aware that the NomCom is looking for input from the
community. This message had a minor error. The NomCom needs to
receive community input by
to work before. It seems fine.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
goes well, we can get updated
documents issued before the next meeting.
Thanks to everyone for their help.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
limited circumstances.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
. So
getting a clear The client didn't like me message to act upen would be
a good thing IMHO.
That heuristic is simple: An EAP conversation is ongoing, and then
pauses for ~10s.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org
and in terms of what to specify to
get the security we need in new standards track methods. So, I think
this could really be worth a bit of discussion at IETF 83.
We'll schedule some time for this at the meeting.
Alan DeKok.
___
Emu mailing list
Emu
. So, putting it mildly, I suspect a lot of
clients will be fairly liberal in accepting unprotected success.
I agree.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
controls the outer TLS session. The attacker knows the MSK.
The keys need to be derived from something the attacker does not know in
order to avoid an attack.
OK.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
.
3) Figure out if we want to do something like what you propose using
long-term credentials for inner methods that don't have an EMSK.
That's a wider discussion for the WG. I'd like to see more input.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
derived from *both* the TLS MSK
and from the users authentication credentials. This would ensure that
MITM attacks are impossible.
I'm interested in seeing a wider discussion of these topics.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https
if there is
WG consensus to make a change we should do so.
I think there's been a lot of discussion on the document. We need to
get closure quickly. This means not re-opening issues which were
previously discussed and decided.
Alan DeKok.
___
Emu mailing
. Echoing nothing means that the server
doesn't know what to do with the attribute. Echoing an attribute with
an empty value means... what?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Joe Salowey wrote:
This is the working group last call for draft-ietf-emu-chbind-09. Please
send your comments to the list by October 21, 2011.
I've read the document, and have comments as follows.
Section 4.3 Page 11:
For example, information carried
in AAA attributes such as
to send them than
to send nothing at all.
This prohibition not withstanding, these
attributes SHOULD be sent with no value in channel binding responses.
I am not clear why the document makes that suggestion. If it's a
SHOULD, there should be explanation as to why it's a good idea.
Alan
before the meeting. This will allow the authors
to have a detailed list of issues to resolve, or questions to answer.
Please provide questions by the start of IETF (2 weeks). The EMU
meeting is early in the week, so there will not be time to review it
during the meeting.
Alan DeKok
Glen Zorn wrote:
On 5/17/2011 2:33 PM, Alan DeKok wrote:
We're asking for input, not a decision right now.
Why not?
I'd like to see what the WG consensus is prior to making a decision.
In addition, I'd like to be sure we understand the consequences of a
change, before we make
to create a v2 only implementation?
I will partially avoid those two questions, and say that it should be
possible to deploy only the EMU tunneled method.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
existing code and
deployment, with small changes to meet EMU requirements. Changing the method
name and type would totally negativate that.
I'm not sure how changing the type code adds deployment costs. The
new version has to be deployed no matter what.
Alan DeKok
Glen Zorn wrote:
There seem to be two issues here: renaming the draft allocating a new
EAP type. For which one are opinions being solicited?
Allocating a new EAP type.
The draft name eap-tunnel-method describes the protocol accurately.
Alan DeKok
with opinions either way is requested to discuss the pros and
cons of the issue.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Joe Salowey wrote:
1. Do you agree with the direction taken in draft-ietf-emu-chbind-07. More
specifically the usage of a channel binding specific TLV, the support of
multiple name spaces, and that the server indicates to the client what
attributes were validated.
Yes.
2. Two
. There should be little cost to re-using
that, and a larger cost in writing a new attribute packer.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
(speaking as individual contributor)
#1 - Yes, I agree.
#2 - encoding method #2
Joe Salowey wrote:
This consensus call closes next week. This is an important working group
work item. If you have an opinion about this issue please send it to the list
so we can keep the work moving
Sam Hartman wrote:
I just want to confirm I haven't missed mail.
It's my understanding that the call for proposals for tunnel methods
closes March 7 and that so far we've seen no submissions.
Is that correct?
Yes.
Alan DeKok.
___
Emu mailing
to be
aligned. Does that requirement continue for the channel-bindings data?
Or can we just pack Diameter data into an opaque blob, and wrap a 2-4
byte channel binding header around it?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman
(1.a) Who is the Document Shepherd for this document?
== Alan DeKok.
Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication
-- Forwarded message --
From: NomCom Chair nomcom-ch...@ietf.org
Date: Thu, Sep 16, 2010 at 6:26 PM
Subject: NomCom 2010-2011: Call for More Nominations
To: IETF Announcement list ietf-annou...@ietf.org
Hi Folks,
Nominations have slowed down dramatically, so this update is to
.
For the attack to work on the client, it requires that the client set
up an anonymous tunnel with the attacker, and send credentials down that
tunnel. If the client were to associate the credentials with a server
cert, the attack could be detected.
Alan DeKok
a personal draft.
Sam's suggestion (IIRC) was to merge the two documents. The channel
binding document is small, and may be better served by specifying the
protocol, too.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman
to, is that a third-party
chooses the privacy requirements for the home system. In that view,
your question is highly relevant. Since it's not a view I hold, I
cannot answer your question in any meaningful way.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
could perform the certificate checks
against the local network information, so that would require standards
action, too.
And I'm not sure why this applies only to TTLS. I see this as
applying equally well (or poorly) any other TLS-based EAP method.
Alan DeKok
Glen Zorn wrote:
Alan DeKok [mailto:al...@deployingradius.com] writes:
This proxying violates the privacy requirements.
What privacy requirements are those?
The requirement to keep authentication credentials private, which is
one of the reasons for choosing a TLS-based method
who've deployed local TLS + password login methods see it as
insufficient. They pretty much have the solution proposed by Glen, and
they want something more.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Glen Zorn wrote:
Note that transitive trust issues are irrelevant if EAP-TTLS is used.
I agree with Sam here. I'd like to see more explanation behind this
assertion.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman
Stephen McCann wrote:
imho, I'd not place any trust in an SSID.
Its just a 32 octet string that can be set to anything, and provides
no guarantee about the identity of a WLAN.
It's useful as an example.
Alan DeKok
Glen Zorn wrote:
Alan DeKok [mailto:al...@deployingradius.com] writes:
and an indication that the home AAA approves
of the connection.
Hmm. I could have sworn that this indication already existed, in the form
of Access-Accept (for RADIUS).
And EAP-Success. Exactly.
It's part
Glen Zorn wrote:
Is there an RFC that says this somewhere?
RFC 3580, Section 3.20
802.11-2007 doesn't mention
Called-Station-ID; 802.1X-2004 says this:
D.3.20 Called-Station-Id
For IEEE 802.1X Authenticators, this attribute is used to store the Bridge
or Access Point MAC address,
about SSIDs violates trust.
But fraud doesn't?
Yes, fraud violates trust. My original post included an example of
fraud, stated why this was bad, and how channel bindings could help.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https
and chairs on this proposed
approach.
I think it's a good approach.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
for that SSID.
But it's not the role of EAP to change the configuration.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
SeongHan Shin wrote:
Could you please let me know when the deadline of IPR disclosure is?
Before the meeting.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
that a patent application has been
filed, but no IPR disclosure has been submitted. Contributing to or
participating in IETF discussions about a technology without making
required IPR disclosures is a violation of IETF process.
Alan DeKok.
___
Emu mailing list
(sorry, hit send too soon)
SeongHan Shin wrote:
Dear Alan DeKok,
I'm Shin.
I submitted the below I-D (00) and want to introduce our work.
Could you please let me know if it is possible for me to present
our work in emu WG?
Section 6 of the document says that a patent has been filed
---BeginMessage---
IETF working group chairs;
We are developing an open-source tool for monitoring the status and
progress of conflicts in on-line working groups (WG). The tool works by
analyzing the WG mailing list. When developed, this tool should be
helpful to WG chairs trying to understand
, not a public CA).
Enterprises usually have areas which are physically secure, and that
can be used to bootstrap the system.
Anonymous provisioning is more useful for ISPs and telcos, who need to
provision users in random places.
Alan DeKok
where authentication can continue after a NAK?
A NAK of a mandatory attribute should be treated as a failure.
Otherwise, what does mandatory mean, if it can be ignored?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo
to the current draft).
Hmm... I'd like to understand exactly what a NAK means, then. The
use-cases and failure scenarios aren't clear to me.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
are the expected consumers of the document?
Anyone can read the ITU document, but who will be paying attention to
it, and following its recommendations?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
a username and password for
authentication MUST be through interaction and not computation.
The first sentence refers to authentication server, while the second
uses EAP server. I suggest using EAP server for both, as it is
used elsewhere in the document, too.
Alan DeKok
to send a clear-text password in a
tunnel. I am therefore opposed to it, for reasons I have outlined
earlier. I understand that you find your text more specific than the
current text in the document. I do not.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
on a
tunneled protocol that fails to support clear-text passwords.
I welcome text to clarify the security requirements. But I am opposed
to removing the stated requirement for clear-text passwords. Everything
else we've discussed is secondary to that point.
Alan DeKok
.
I think this addresses your concerns, while simultaneously stating
clearly the specific requirements.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
getting at.
Can you propose specific modifications to the text? i.e. quote the
current text, and then write what you think it should say.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
, are we mandating TLS? If so, this should be clarified earlier
in the document.
6.4. Separation of TLS Tunnel and Inner Authentication Termination
...
... This
may not meet the security policy of many environments.
There is a stray in the document.
Alan DeKok
to support other housekeeping functions,
such as the management of PINs or other data, required by some
systems.
That looks good to me.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
---BeginMessage---
Hi all,
Thanks to the ADs and chairs that forwarded the previous reminder to
their mailing lists. I would appreciate it if other chairs and ADs could
do so, since we are really in need of more nominations.
Thanks,
Mary.
-Original Message-
From:
,
some say no.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
.
Please do not build EAP session breaking assumptions into AAA implementations.
It would be useful to codify these experiences into an EAP best
practices document.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
to offer.
Are we really authenticating the NAS, and then authorizing it, by
passing tunneled data in EAP? Do we really want to go down that path?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
solves all
open issues with the draft.
I believe that this feature is useful enough to warrant mentioning in
the draft.
If there is objection, we can have a WG consensus call on this issue.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https
: Authenticators would like to
know certain information before returning success or fail in EAP.
Within some limitations, where that information can be carried in EAP, I
believe it is appropriate and useful to carry it in EAP.
Alan DeKok.
___
Emu mailing list
Emu
. After all, enforcement of applicability statements is a very hit
or miss thing in the IETF. You may get lucky. :-)
I would prefer to get WG consensus first. If the WG believes it's a
good idea, the re-chartering process becomes simpler.
Alan DeKok
Glen Zorn wrote:
Alan DeKok [mailto://al...@deployingradius.com] writes:
...
Prior to authentication, EAP is the only communications protocol
between a supplicant and *anywhere* on the network. It is therefore
natural to overload it as a general purpose transport protocol.
To transport
what criteria you use to distinguish between authentication
data and authorization data. Give a name to the policies that get
processed *before* a user is authenticated.
Such policies exist, and are in wide use. The NEA use of EAP falls
within this use.
Alan DeKok
to the
authentication server.
That is reasonable.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
discussion. I think that clarification is
necessary.
Given current state of affairs, having a tunneled method that is not
tied to a specific cryptographic algorithm seems beneficial to me. The
concern with this is that cryptographic negotiation is hard.
Alan DeKok
501 - 600 of 645 matches
Mail list logo
