e email list.
I am in favor of EAP-TTLSv0 + new AVP's.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
; be evaluating PEAP and EAP-FAST as alternatives as they also meet the
> requirements and perhaps more so than TTLS.
I believe that the evaluation is ongoing on this list.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
er seen an EAP-FAST deployment, and most people I talk to haven't
seen one, either. Most people I talk to don't plan on supporting
EAP-FAST any time soon.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
misperception that EAP-FAST has a large market presence
has been that the people who are deploying it don't talk to the people
*not* deploying it, and vice versa. Within the EAP-FAST camp, it looks
like there's wide-spread adoption. Outside of it, it just d
port, no policy language, etc.
If there is an EAP-FAST patch for FreeRADIUS, I'd like to see it.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
erception
statistically significant. That's just what market analysts do.
> The adoption characteristic was naturally different from TTLS or PEAP.
The only relevant characteristic is volume of deployments.
Alan DeKok.
___
Emu mailing list
E
The additional EMU requirements can be addressed in a separate document.
This process lets us get something done quickly. I would prefer to
void spending years talking about a new EAP method, followed by years of
trying to get it widely deployed.
Alan
via AVP's with the "M" bit set. Existing
clients would know enough to fail when they saw an "M" bit set on an AVP
that they didn't understand.
Do you expect that crypto-binding/agility features would require
changes tha
to label the
> character set, discuss any normalization that the client should do
> (often none) and set interoperability goals.
The whole composed / decomposed thing is a nightmare for passwords.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
end an opaque sequence of bytes to the
authentication server. The authentication server shouldn't interpret
those bytes, it should just compare them to previously stored credentials.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
erally
also has information about the language and locale. Once normalization
is performed, the password can be sent over the wire *without* language
or locale information to the server.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
27;t see why they would need to normalize passwords for
composed/decomposed characters.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
es of EMU. Therefore, UTF-8 sequences must consist solely of
composed characters.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Stephen Hanna wrote:
> I favor option 2.
As do I.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
oo many bit players who lack the capability to do
anything other than to bill users.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
prove of the charter revision, and can contribute to the tunneled
method development as a reviewer, possibly as a contributor.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
http://www.ietf.org/mailman/listinfo/emu
compact for implementation in
resource constrained environments.
Status:
- GPSK (http://tools.ietf.org/html/draft-ietf-emu-eap-gpsk-08)
Waiting on revision from authors to address AD comments.
Alan DeKok
___
Emu mailing list
Emu@ietf.org
https
While the charter updates are being formally approved, we can start
discussions about the new work items. Please respond with comments,
queries, or feedback on the items listed below.
Work item:
- Charter updates
Status:
The charter revision is in IESG evaluation.
While the charter updates are being formally approved, we can start
discussions about the new work items. Please respond with comments,
queries, or feedback on the items listed below.
Work items:
- A document that defines EAP channel bindings and provides
guidance for establishing EAP channel
While the charter updates are being formally approved, we can start
discussions about the new work items. Please respond with comments,
queries, or feedback on the items listed below.
Work item:
- A mechanism to support extensible communication within a
TLS protected tunnel. This mechanism mus
This is a consensus call for acceptance of the tunnel requirements draft
as an EMU WG work item. The consensus call will last until June 20,
2008. Please send email to the list stating whether you are in favor or
opposed to accepting this document as an EMU WG work item.
http://tools.ietf.org/i
between the EAP tunneling
protocol and the tunneled EAP methods.
Hence the current WG work items on cryptographic binding.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
nes.
Sorry, my mistake.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
therefore submit the document as an EMU WG
document. Please use the name:
draft-ietf-emu-eaptunnel-req-00.txt
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
This is a call for agenda items for the EMU WG meeting at IETF 72 in
Dublin. The meeting is tentatively scheduled for Friday August 1 2008
from 9 AM - 11:30 AM.
If you have an item that you would like to have on the agenda, please
contact myself or Joe Salowey <[EMAIL PROTECTED]>
The following is the draft agenda for IETF 72. If there are no
comments or additions, it will be submitted later this week to the IETF
web site.
Agenda for IETF 72:
Blue sheets and Agenda updates
5 minutes
draft-ietf-emu-eaptunnel-req-00.txt
60 minutes
Intermezzo (Some people need to leave
Dan Harkins wrote:
> I think this is a very good idea. +1 and all that jazz. I hope some
> time can be alloted to discuss this.
There is time. We can add the document to the end of the current agenda.
Alan DeKok.
___
Emu mailing li
The following people have volunteered to review the tunnel
requirements draft.
Stefan
Kaushik
Klaas
Dave Mitton
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
room at IETF was that the lengths should be independent. We are
looking for WG consensus on this issue.
Please respond FOR or AGAINST making the input and output lengths
independent. This consensus call will last until August 19.
Alan DeKok
(forwarding a message from Joel)
---
Third Nomcom 2008-9 Call for Volunteers!
I am pleased to report that there are 48 volunteers whose
qualifications have been confirmed by the secretariat.
There are 9 more volunteers awaiting confirmation.
However, We need more volunteers.
Please!
Yes, you have
http://www.ietf.org/proceedings/08jul/minutes/emu.txt
Please note any corrections or updates here.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
please update the draft to make the input and
output key lengths independent.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
.1 allows additional data to be transmitted after
the NUL in an Identity Request. This could perhaps be leveraged to send
a string such as "UTF-8", which could indicate to the supplicant that
the server is requesting UTF-8 encoding.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
doubt it can work that
> way in a 802.1X deployment.
The alternative is for supplicants to simply start using UTF-8. It's
likely a good idea, in any case.
A compatibility option would be for the server to look at it's list of
known users, and convert them (where appropriate
ly popular approach. And RFC4282 includes it as valid
> explicitly.
People use non-ASCII strings for identities. Breaking this is not nice.
However, using UTF-8 is likely a better choice than depending on
implementation-specific behavior.
Alan DeKok.
__
Forward on behalf of the Noncom chair:
The 2008-9 IETF Nominating Committee needs your help.
We have started getting candidates.
If we are going to do our job in time, we have only 3 more weeks to get
enough candidates to have a reasonable pool for all the jobs.
At the moment, we do not have a r
art on that.
> b. A document on EAP internationalization, updating RFC 3748. This
> would cover the EAP-Response/Identity as well as potentially giving
> advice on issues such as password internationalization and
> internationalization of the EAP Peer-Id and Server-Ids.
I'l
s used. User-Name, CUI, and
>> other protocols such as Kerberos.
>
> RFC 4372 (CUI) Section 2.2 doesn't say anything at all about
> internationalization:
The CUI is often created as "[EMAIL PROTECTED]". i.e. based off of the
8 as well as ASCII, no?
Yes. If the "example.com" portion is interpreted by any party, it has
to be dealt with the same as the corresponding portion of the User-Name.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
68656c6c6f); of course this is assuming that you know what
binary data the authentication server expects to see.
Checking the source, there are no references to UTF-8 in anything
other than comments.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
IETF 73 is approaching soon, and we need to ensure that make progress
on the current WG activities. To that end, I am repeating previous
posts about WG status items.
Alan DeKok wrote:
> While the charter updates are being formally approved, we can start
> discussions about the new work
Are there additional reviews / reviewers before IETF 73?
Alan DeKok wrote:
> While the charter updates are being formally approved, we can start
> discussions about the new work items. Please respond with comments,
> queries, or feedback on the items listed below.
>
> Work
other WG activies.
Alan DeKok wrote:
> While the charter updates are being formally approved, we can start
> discussions about the new work items. Please respond with comments,
> queries, or feedback on the items listed below.
>
> Work item:
>
> - A mechanism
characters into the EAP-Response/Identity
field, rather than using UTF-8.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
This is a WG call for agenda items for IETF 73. Please email the
chairs with a pointer to a draft, and a request for a specific length of
time.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
:15 - 10:30 RFC 4282 Internationalization - Alan DeKok
(no draft)
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
This is a consensus call on accepting draft-clancy-emu-chbind-04.txt
as a WG work item. The consensus call will last until Friday, November 28.
Please response either YES or NO to accepting the draft as a WG work item.
Alan DeKok.
___
Emu
This is a reminder on the consensus call for accepting the channel
bindings draft as a WG document.
If there are no objections by COB today, we will assume that WG
consensus is to accept the document.
Alan DeKok wrote:
> This is a consensus call on accepting draft-clancy-emu-chbind-04.
Alan DeKok wrote:
> This is a consensus call on accepting draft-clancy-emu-chbind-04.txt
> as a WG work item. The consensus call will last until Friday, November 28.
>
> Please response either YES or NO to accepting the draft as a WG work item.
There have been no comm
I'm copying a message Bernard sent to RADEXT about RFC 5378 issues:
As some of you may know, as a result of the publication of RFC 5378, the
IETF has changed the boilerplate required for Internet-Draft submissions.
It is important that all contributors know the terms under which
contributions a
or provisioning, so "all" the bad guy gets is the
> resulting MS-CHAPv2 hash which can then be attacked directly and
> off-line. In the worst case the supplicant allows GTC to be used for
> provisioning and the clear text credentials are handed over to the
> attacker.
scratch. The candidates
> sure seem to be TTLS and FAST, given the presentations on them we've had.
Discussing the applicability, cost, benefit, etc. of EAP-FAST is a
good idea. Re-visiting its architectural choices isn't something we
hav
Some issues are less important. e.g. The TLS PRF being dependent on
(client + server), or (server + client) random. Unless there are
security issues related to a particular choice of order, the use of one
order or another shouldn't be factor in choosing
equirements document are a higher priority right now,
because that document is unfinished.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Glen Zorn wrote:
> Alan DeKok [mailto:al...@deployingradius.com] writes:
>> Discussing the applicability, cost, benefit, etc. of EAP-FAST is a
>> good idea. Re-visiting its architectural choices isn't something we
>> have time for.
>
> In other words, no technic
ual", but which also do not impact
the methods ability to satisfy the tunnel requirements are out of scope
of the charter. They can be discussed here with respect to the EAP-FAST
documents && the current IESG review, but they should have no impact on
the choice of tunneled method.
Alan D
, we're only allowed to discuss
> whether both contestants for Miss EMU are technically female but not
> whether one is a gimp hunchback with worts?
Ease of implementation and deployment is one useful criteria out of many.
Alan DeKok.
___
Emu ma
to review the EAP methods against the tunnel
requirements document.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
harter says.
The charter does not require us to choose a particular method.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ethods of your own
invention.
So far, only TTLS and FAST have been discussed. In the absence of
additional proposals, we will likely be extending an existing method.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
This is a call for agenda items for IETF 74. Interested parties
should email the chairs, and ask for a time slot.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
The following is the draft agenda for IETF 74. Please email the
chairs for any concerns or updates.
Blue sheets and Agenda updates
5 minutes
draft-ietf-emu-eaptunnel-req-02.txt
60 minutes
draft-clancy-emu-chbind-04.txt
25 minutes
draft-clancy-emu-aaapay-01.txt
10 minutes
draft-sheffer-em
st.
EMU is meeting Wednesday March 25, at 15:00. If there are no
comments, we will take the opportunity for one last overview of the
document, and then we will submit it for publication.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Would the people on the agenda in the EMU slot next week please send
the chairs their presentations.
Thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Are up on the IETF web site:
https://datatracker.ietf.org/meeting/74/materials.html
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t consistent with
> the TTLS RFC. FreeRadius’s TTLS implementation also uses this option in
> its TLS handshake phase.
All I can say is that it's inter-operable with everything out there.
In any case, future releases will have this behavior conf
rification 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.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
We currently have a 2 hour slot on Monday afternoon. Please submit
agenda requests to the chairs as soon as possible.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
sword to the
> authentication server.
That is reasonable.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
clearer in the documents.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
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 transp
cation decisions would be
perfectly secure: No one would ever be authenticated.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
decisions would
>> be
>> perfectly secure: No one would ever be authenticated.
>
> I have no idea what you're talking about.
Explain what criteria you use to distinguish between "authentication"
data and "authorization" data. Give a name to the pol
e.
Your presentation so far has been "Glen says it's OK", or "Glen says
it's not OK". That isn't anything we can put into a specification.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
whether removing this feature 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 mailin
f we can't agree on a consistent set of terminology, perhaps you
could give your opinion on *what* information is being carried in EAP,
and whether or not that information is useful or inappropriate.
My opinion has been clear and consistent: Authenticators would
t; clarification from the IESG as to whether they think that the current
> "domain of applicability" for EAP embraces the "additional data" you want to
> include. After all, enforcement of "applicability statements" is a very hit
> or miss thing in th
on I think there is a much
> bigger gray area.
ERP is leveraging EAP to obtain authentication and authorization at
later points in time. This seems to be acceptable.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Russian network.
That is largely an issue of fraud, and best *resolved* through legal
methods. But channel bindings may permit the end user to *detect* the
fraud, at least.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
f data over EAP, among others.
> 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
says it is?
... and is he authorized to provide the services he's claiming 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
think that the answer to (a) is "yes", and (b) is "some say yes,
some say no".
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
f doing this. That is one approach.
> Disregarding the EMU charter for a minute, would this be a better
> architectural solution?
Yes.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
> exchange SHOULD be extensible 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
--- Begin Message ---
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: ietf-announce-boun..
d
inter-operability.
The nice thing about that requirement is that it is very compatible
with sites choosing to not use Net-UTF-8. If they choose to put
something else in a DB as the authentication credentials, it will work
so long as the supplicant puts exactly
things to be robust. If normalization
> only happens in one implementation, things will be predictable.
RFC 5198 specifies a normalized form. If two implementations
"normalize" to the RFC 5198 form differently, one of them is wrong.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ecause the *old* characters
have not been re-assigned in the *new* standard
(b) creates a different output string than the old system,
because either the standard is not backwards compatible,
or the implementation is wrong.
nd if the passwords input to the hash
aren't the same (i.e. non-normalized), then you're *guaranteed* that the
hashes won't match.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
The text looks OK to me.
My only concern is that standardizing i18n in *each* possible EAP
document is duplicating work. If we end up with only one tunnel method
that is standardized, then there's less of a problem.
Alan DeKok.
___
Emu mailing l
uite Selection
TLS supports ...
... Since a tunnel method uses the TLS tunnel to transport
data, ...
Again, 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.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
e only thing we can
safely do here is suggest ways to minimize the attacks. e.g. The peer
can request authentication for a realm (@example.com), and validate that
the server certificate is "owned" by that realm. This practice is in
wide-spread use today.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
blem with my suggestion?
No. I just want to be sure I understand what you're 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
against the tunneled method when employing a username and password
for authentication MUST be through interaction and not
computation".
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
e, and would prefer to see specific
requirements. My guess is that if you extend your text to describe the
requirements for clear-text password security, you will be simply
reproducing existing text from elsewhere in the document.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
he properties are satisfied by the requirements
as written. The main disagreement appears to be simply how best to
phrase those requirements.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Dan Harkins wrote:
> You are wrong.
Are you opposed to sending clear-text passwords in the tunnel?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Dan Harkins wrote:
>
>
>I refer the right-honourable gentleman to the answer I gave
>some moments ago.
>
>
Since there has been no new information, I can only conclude that my
previous summary was correct, and that you have no additional concerns
with the docum
Your stated concerns with that paragraph are directly
addressed by existing text elsewhere in the document.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
irement 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 mailin
1 - 100 of 778 matches
Mail list logo
