[Emu] ID Tracker State Update Notice:
IANA action state changed to No IC ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] ID Tracker State Update Notice:
IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] ID Tracker State Update Notice:
IANA action state changed to No IC ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] ID Tracker State Update Notice:
IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] ID Tracker State Update Notice:
State changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] ID Tracker State Update Notice:
IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Document Action: 'EAP Mutual Cryptographic Binding' to Informational RFC (draft-ietf-emu-crypto-bind-04.txt)
The IESG has approved the following document: - 'EAP Mutual Cryptographic Binding' (draft-ietf-emu-crypto-bind-04.txt) as Informational RFC This document is the product of the EAP Method Update Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ Technical Summary EAP tunneled methods require that EAP peers rely on information from the EAP server. Various security related information is carried inside of the tunnel, and are used by the peers. Methods exist to protect the peers against MITM attacks. The document discusses attacks on the tunneled data, and recommends mutual cryptographic binding to protect both parties. Working Group Summary The docuemnt records the consensus of the WG as developed over the last year. Any controversy about the contents has been resolved by updates to the document, and WG consensus was not rough. Document Quality The document provides a clear description of the attacks and recommended solutions. There are no protocol changes in the document, so no implementations are required. Personnel Alan DeKok is the doc shepherd. Sean Turner is the responsible AD. RFC Editor Note Please make the following modifications in section 3.2.3: OLD: First, the server and peer prove to each other knowledge of the inner MSK. Then, the inner MSK is combined into some outer key material to form the tunnel's keys. NEW: First, the server and peer prove to each other knowledge of the inner MSK. Then, the inner MSK is combined with some outer key material to form the tunnel's EAP keys. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Some proposed error conditions for draft-ietf-emu-eap-tunnel-method
Hi, > Stefan> This limits the scope of the error conditions to cases where > Stefan> TEAP has "all in its own hands" - which I believe is limited > Stefan> to the "Optional Password Authentication" of chapter 3.3.2. > > DIsagreed. > AAA servers don't signal all of these up, but AAA servers often signal a > number of these. > For example in Freeradius I could actually figure out a number of these > even across an inner tunnel and could easily expand the server to do > better than that. > However if you have nothing else then you are left with inner method > error. Yes, it occured to me afer sending that my mind model was maybe a bit too strict: there is no /protocol/ way for things to transpire from inner to outer; but there may be be other means (like shared memory in the server process) *if* inner and outer terminate at the same server. If the inner method is proxied elsewhere, then we're out of luck in terms of getting specific error conditions from the inner method; "proper" protocol-based signaling would then be required but doesn't exist. I guess it comes down to wordsmithing to express this correctly; like "will work for TEAP's simple password auth, and *may* work for inner EAP, if inner and outer termination point are co-located, or otherwise have an unspecified out-of-band protocol of their own for signalling error conditions between inner and outer termination point." Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
