Re: [Emu] Crypto-binding in TTLS-v0

2007-08-14 Thread Alan DeKok
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

Re: [Emu] Crypto-binding in TTLS-v0

2007-08-16 Thread Alan DeKok
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

Re: [Emu] Crypto-binding in TTLS-v0

2007-08-16 Thread Alan DeKok
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 Emu@ietf.org https

Re: [Emu] Crypto-binding in TTLS-v0

2007-08-21 Thread Alan DeKok
. 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 DeKok

Re: [Emu] Crypto-binding in TTLS-v0

2007-08-23 Thread Alan DeKok
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

Re: [Emu] Crypto-binding in TTLS-v0

2007-08-24 Thread Alan DeKok
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

Re: [Emu] Crypto-binding in TTLS-v0

2007-08-28 Thread Alan DeKok
/decomposed characters. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu

Re: [Emu] Crypto-binding in TTLS-v0

2007-08-28 Thread Alan DeKok
consist solely of composed characters. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu

Re: [Emu] Moving forward with the EMU password method

2007-10-04 Thread Alan DeKok
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

Re: [Emu] RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls

2007-10-08 Thread Alan DeKok
to bill users. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu

Re: [Emu] Tunnel Method (Current WG Work item status)

2008-06-05 Thread Alan DeKok
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

Re: [Emu] Tunnel Method (Current WG Work item status)

2008-06-06 Thread Alan DeKok
. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

[Emu] Summary of Consensus Call on Tunnel Requirements draft

2008-06-24 Thread Alan DeKok
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

[Emu] Call for Agenda Items for IETF 72

2008-06-24 Thread Alan DeKok
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] Alan DeKok

[Emu] Reviewers for Tunnel Requirements draft

2008-08-01 Thread Alan DeKok
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

[Emu] Volunteers needed for the NomCom process

2008-08-07 Thread 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

[Emu] EMU minutes have been uploaded

2008-08-07 Thread Alan DeKok
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

Re: [Emu] EAP and UTF-8

2008-09-11 Thread Alan DeKok
, 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

Re: [Emu] EAP and UTF-8

2008-09-11 Thread Alan DeKok
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) to UTF-8. Alan DeKok

Re: [Emu] EAP and UTF-8

2008-09-12 Thread Alan DeKok
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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

[Emu] NomCom Call for assistance

2008-09-17 Thread 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

Re: [Emu] EAP, RADIUS, UTF-8, RFC 4282 and SASLPREP: the interop nightmare

2008-09-19 Thread Alan DeKok
-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'll stay away from that. :( Alan DeKok. ___ Emu mailing list Emu@ietf.org https

Re: [Emu] EAP, RADIUS, UTF-8, RFC 4282 and SASLPREP: the interop nightmare

2008-09-19 Thread Alan DeKok
anything at all about internationalization: The CUI is often created as [EMAIL PROTECTED]. i.e. based off of the User-Name. So it's worth double-checking the effects of changing User-Name on all down-stream uses. Alan DeKok. ___ Emu mailing list Emu

Re: [Emu] EAP, RADIUS, UTF-8, RFC 4282 and SASLPREP: the interop nightmare

2008-09-21 Thread Alan DeKok
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

Re: [Emu] EAP, RADIUS, UTF-8, RFC 4282 and SASLPREP: the interop nightmare

2008-09-22 Thread Alan DeKok
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

Re: [Emu] GPSK (Current WG Work item status)

2008-10-19 Thread Alan DeKok
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 items

Re: [Emu] EAP Channel bindings (Current WG Work item status)

2008-10-19 Thread Alan DeKok
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 items: - A document

Re: [Emu] Tunnel Method (Current WG Work item status)

2008-10-19 Thread Alan DeKok
with 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 to support extensible communication

[Emu] i18n issues with RFC 4282 (NAI)

2008-10-31 Thread Alan DeKok
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

[Emu] Agenda items for the next meeting

2008-10-31 Thread Alan DeKok
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

[Emu] Proposed EMU Agenda for IETF 73

2008-11-02 Thread Alan DeKok
: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

[Emu] Consensus call on accepting draft-clancy-emu-chbind-04.txt as WG item

2008-11-20 Thread Alan DeKok
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

Re: [Emu] Consensus call on accepting draft-clancy-emu-chbind-04.txt as WG item

2008-11-28 Thread Alan DeKok
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.txt

Re: [Emu] Consensus call on accepting draft-clancy-emu-chbind-04.txt as WG item

2008-12-02 Thread Alan DeKok
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 comments on this consensus

[Emu] RFC 5378 Implications

2009-01-15 Thread Alan DeKok
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

Re: [Emu] Potential Issues with EAP-FAST

2009-01-25 Thread Alan DeKok
are handed over to the attacker. Something similar can happen with EAP-TTLS / PAP, if the supplicant does not validate the server certificate. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Potential Issues with EAP-FAST

2009-01-26 Thread Alan DeKok
. 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 have time for. Alan DeKok

Re: [Emu] Potential Issues with EAP-FAST

2009-01-26 Thread Alan DeKok
. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Potential Issues with EAP-FAST

2009-02-06 Thread Alan DeKok
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 technical review. OK, great, how about we just

Re: [Emu] Potential Issues with EAP-FAST

2009-02-07 Thread Alan DeKok
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 mailing list Emu@ietf.org https

Re: [Emu] Potential Issues with EAP-FAST

2009-02-07 Thread Alan DeKok
requirements document. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Potential Issues with EAP-FAST

2009-02-08 Thread Alan DeKok
us to choose a particular method. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Potential Issues with EAP-FAST

2009-02-08 Thread Alan DeKok
, 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

[Emu] Call for agenda items for IETF 74

2009-02-24 Thread Alan DeKok
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

[Emu] LAST CALL FW: I-D Action:draft-ietf-emu-eaptunnel-req-02.txt

2009-03-09 Thread Alan DeKok
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

[Emu] Call for slides

2009-03-21 Thread Alan DeKok
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

[Emu] Materials for the WG meeting

2009-03-25 Thread Alan DeKok
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

Re: [Emu] comments on draft-ietf-emu-eaptunnel-req-02.txt, part 1

2009-06-11 Thread Alan DeKok
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

Re: [Emu] Issue #7: Password Authentication

2009-08-06 Thread Alan DeKok
to the authentication server. That is reasonable. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP and authorization

2009-08-11 Thread 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

Re: [Emu] EAP and authorization

2009-08-11 Thread Alan DeKok
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

Re: [Emu] EAP and authorization

2009-08-12 Thread Alan DeKok
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

Re: [Emu] EAP and authorization

2009-08-12 Thread Alan DeKok
: 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

Re: [Emu] EAP and authorization

2009-08-12 Thread Alan DeKok
. 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

Re: [Emu] EAP and authorization

2009-08-14 Thread Alan DeKok
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

Re: [Emu] EAP and authorization

2009-08-16 Thread Alan DeKok
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

Re: [Emu] EAP and authorization

2009-08-16 Thread Alan DeKok
. 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

Re: [Emu] EAP and authorization

2009-08-16 Thread Alan DeKok
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

Re: [Emu] EAP and authorization

2009-08-18 Thread Alan DeKok
, some say no. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] where to exchange protected TLVs

2009-08-30 Thread Alan DeKok
, would this be a better architectural solution? Yes. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue #17: What is housekeeping

2009-09-09 Thread 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

[Emu] [Fwd: FW: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available]

2009-09-09 Thread Alan DeKok
---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:

[Emu] Review of draft-ietf-emu-eaptunnel-req-04.txt

2009-10-27 Thread Alan DeKok
, 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

Re: [Emu] Issue #7: Password Authentication

2009-12-01 Thread Alan DeKok
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

Re: [Emu] Issue #7: Password Authentication

2009-12-02 Thread 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

Re: [Emu] Issue #7: Password Authentication

2009-12-02 Thread Alan DeKok
existing text from elsewhere in the document. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Issue #7: Password Authentication

2009-12-03 Thread 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

Re: [Emu] Issue #7: Password Authentication

2009-12-03 Thread Alan DeKok
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

Re: [Emu] Issue #7: Password Authentication

2009-12-04 Thread Alan DeKok
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

Re: [Emu] New Liaison Statement, Draft revised Recommendation ITU-T X.1034, Guideline on extensible authentication protocol based authenticationand key management in a data communication network

2009-12-10 Thread Alan DeKok
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

Re: [Emu] Tunnel Method Requirements - mandatory attributes

2010-03-02 Thread 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

Re: [Emu] Tunnel Method Requirements - mandatory attributes

2010-03-02 Thread Alan DeKok
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

[Emu] [Fwd: request for help in developing a tool that may be helpful to WG chairs]

2010-03-03 Thread Alan DeKok
---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

Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04

2010-03-03 Thread Alan DeKok
, 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

Re: [Emu] Call for agenda items

2010-03-06 Thread Alan DeKok
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. However, there is no IPR

Re: [Emu] Call for agenda items

2010-03-06 Thread Alan DeKok
(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

Re: [Emu] Call for agenda items

2010-03-07 Thread Alan DeKok
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

Re: [Emu] Call for agenda items

2010-03-07 Thread Alan DeKok
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

Re: [Emu] Channel Binding Discussion at IETF 77

2010-06-19 Thread Alan DeKok
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

Re: [Emu] Channel Binding Discussion at IETF 77

2010-06-19 Thread Alan DeKok
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

Re: [Emu] Channel Binding Discussion at IETF 77

2010-06-20 Thread 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

Re: [Emu] Channel Binding Discussion at IETF 77

2010-06-20 Thread Alan DeKok
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,

Re: [Emu] Channel Binding Discussion at IETF 77

2010-06-20 Thread Alan DeKok
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

Re: [Emu] Channel Binding Discussion at IETF 77

2010-06-21 Thread Alan DeKok
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

Re: [Emu] Channel Binding Discussion at IETF 77: why bother

2010-06-22 Thread Alan DeKok
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

Re: [Emu] Channel Binding Discussion at IETF 77: why bother

2010-06-24 Thread Alan DeKok
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

Re: [Emu] Channel Binding Discussion at IETF 77: why bother

2010-06-24 Thread 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

Re: [Emu] Channel Binding Discussion at IETF 77: why bother

2010-06-24 Thread Alan DeKok
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

Re: [Emu] Channel Binding Discussion at IETF 77: why bother

2010-06-25 Thread Alan DeKok
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

Re: [Emu] make EAP Method Support for Transporting AAA Payloads WG item

2010-07-30 Thread 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

Re: [Emu] How does cryptographic binding work

2010-09-02 Thread Alan DeKok
. 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

[Emu] [Fwd: NomCom 2010-2011: Call for More Nominations]

2010-09-17 Thread Alan DeKok
-- 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

[Emu] PROTO write-up for draft-ietf-emu-eaptunnel-req-08.txt

2010-10-19 Thread Alan DeKok
(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

Re: [Emu] Channel Bindings: RADIUS or Diameter namespace

2011-02-10 Thread Alan DeKok
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

Re: [Emu] Really no proposals submitted so far?

2011-03-03 Thread Alan DeKok
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

Re: [Emu] Consensus call on EAP Tunneled method

2011-04-15 Thread Alan DeKok
We had 4 responses on the list, in addition to the discussion at IETF. Q1: 4 yes 0 No Q2: 3 EAP-FASTv2 1 EAP-TEAM The WG consensus is that EAP-FASTv2 should be the tunnel method. Alan DeKok wrote: For people who didn't attend the EMU meeting at IETF, please answer the following

Re: [Emu] Consensus call on EAP Tunneled method

2011-04-16 Thread Alan DeKok
and reviewed my EMU folder, and Katrin is correct. Sorry for the miscount. As you not, this does not change the rough consensus of the WG, where the majority at IETF supported FASTv2. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman

Re: [Emu] Reminder: Channel Binding Consensus Call

2011-04-27 Thread Alan DeKok
(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

Re: [Emu] Reminder: Channel Binding Consensus Call

2011-04-28 Thread Alan DeKok
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

Re: [Emu] Channel Binding Consensus Call

2011-04-28 Thread Alan DeKok
. 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

  1   2   3   4   5   >