RE: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
I agree with Lakshminath on this. From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Wed 4/11/2007 11:03 PM To: Sam Hartman Cc: ietf@ietf.org; Bernard Aboba; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings Hi Sam, Here is my take on this topic: After having reviewed draft-williams-on-channel-binding-01, I feel that putting EAP in scope of that document would require a rather involved revision of the document. As Charles noted it might require further abstraction of the concept of channel binding as defined in draft-williams. Now, I must say, I do see the similarities between the two notions of channel binding. But the EAP/AAA model is unique and it is not easy to map it to the other, let's say simpler, security models. The notion of compound binding or crypto binding also has some similarities to the notion of channel binding in draft-williams-on-channel-binding-01, but there are also some differences. Overall though, since expanding draft-williams-on-channel-binding-01's scope to EAP means that the requirements, recommendations and suggestions of Section 2.1 may be applied to EAP channel binding, it would be a rather painful exercise to sort it all out. For now, I am comfortable with the guidance in Section 7.15 of 3748. thanks, Lakshminath Sam Hartman wrote: Hi. For the last couple of years, we've been believing that EAP and GSS used the term channel bindings inconsistently. For those of us dealing with both, it's been a bit annoying. I've been thinking about EAP a lot lately. and have come to the conclusion that actually the terms are used consistently. I'd like to see if people agree with the following change to Nico's channel binding draft: old: Also unfortunately there is a conflict with the Extensible Authentication Protocol (EAP) [RFC3748] which uses channel binding to refer to a facility that is subtly different from the one described here. (It does not seem feasible to adopt new terminology to avoid these problems now. The GSS-API, NFSv4 and other communities have been using the terms channel binding and channel bindings in these ways for a long time, sometimes with variations such as channel binding facility and so on.) new: The Extensible Authentication Protocol (EAP) [RFC3748] includes two facilities related to channel binding. The first, called channel binding, is used to bind the lower-layer channel created between the peer and the authenticator to the authentication performed using EAP. Specific detials of this facility have not been specified, but it is likely that this channel would use endpoint channel bindings carried in the EAP method exchange. The endpoint channel bindings would be defined for the specific lower layer. EAP also has a facility called cryptographic binding, which is another instance of channel binding. Cryptographic binding refers to binding the channel created by a tunneling EAP method to an inner authentication performed within that method. Cryptographic binding will likely use unique channel bindings. Do these changes make sense to people? Am I telling any lies or conflating two architectures in a bad way? ___ Emu mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/emu ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
Below are diffs to draft-williams-on-channel-binding-01.txt including: - Alexey Melnikov's IANA text - Fixes to Eric Gray's nits - New text about EAP channel binding - A clarification requested by Sam: this doc describes a generic notion of channel binding, not [just] the GSS-API's Please review and comment. Particularly w.r.t. EAP channel binding. --- on-channel-binding-01.txt +++ on-channel-binding-02.txt @@ -1,18 +1,18 @@ NETWORK WORKING GROUPN. Williams Internet-Draft Sun -Expires: September 6, 2007 March 5, 2007 +Expires: October 18, 2007 April 16, 2007 On the Use of Channel Bindings to Secure Channels -draft-williams-on-channel-binding-01.txt +draft-williams-on-channel-binding-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. @@ -27,17 +27,17 @@ material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on September 6, 2007. + This Internet-Draft will expire on October 18, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). @@ -47,19 +47,19 @@ -WilliamsExpires September 6, 2007 [Page 1] +WilliamsExpires October 18, 2007[Page 1] -Internet-Draft On Channel BindingsMarch 2007 +Internet-Draft On Channel BindingsApril 2007 Abstract The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to @@ -71,59 +71,59 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 1.1.Conventions used in this document . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . 5 2.1.Properties of channel binding . . . . . . . . . . . . 6 + 2.2.EAP channel binding . . . . . . . . . . . . . . . . . 8 3. Authentication and channel binding semantics . . . . . 9 3.1.The GSS-API and channel binding . . . . . . . . . . . 9 3.2.SASL and channel binding . . . . . . . . . . . . . . . 9 4. Channel bindings specifications . . . . . . . . . . . 11 4.1.Examples of unique channel bindings . . . . . . . . . 11 4.2.Examples of end-point channel bindings . . . . . . . . 11 5. Uses of channel binding . . . . . . . . . . . . . . . 13 6. Benefits of channel binding to secure channels . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . 16 - 8. Security Considerations . . . . . . . . . . . . . . . 17 + 7.1.Registration Procedure . . . . . . . . . . . . . . . . 16 + 7.2.Comments on channel bindings Registrations . . . . . . 17 + 7.3.Change control . . . . . . . . . . . . . . . . . . . . 18 + 8. Security Considerations . . . . . . . . . . . . . . . 19 8.1.Non-unique channel bindings and channel binding - re-establishment . . . . . . . . . . . . . . . . . . . 17 - 9. References . . . . . . . . . . . . . . . . . . . . . . 19 - 9.1.Normative References . . . . . . . . . . . . . . . . . 19 - 9.2.Informative References . . . . . . . . . . . . . . . . 19 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22 - Author's Address . . . . . . . . . . . . . . . . . . . 23 - Intellectual Property and Copyright Statements . . . . 24 + re-establishment . . . . . . . . . . . . . . . . . . . 19 + 9. References . . . . . . . . . . . . . . . . . . . . . . 21 + 9.1.Normative References . . . . . . . . . . . . . . . . . 21 + 9.2.Informative References . . . . . . . . . . . . . . . . 21 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 24 + Author's Address . . . . . . . . . . . . . . . . . . . 25 + Intellectual Property and Copyright Statements . . . . 26 +WilliamsExpires October 18, 2007
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
On Mon, April 9, 2007 6:38 pm, [EMAIL PROTECTED] wrote: Charles == Charles Clancy [EMAIL PROTECTED] writes: Charles Sam Hartman wrote: Charles == Charles Clancy [EMAIL PROTECTED] writes: Charles I don't think I'm convinced that EAP channel bindings are Charles doing this binding to the L2 channel. The identity used Charles in an EAP channel binding must be bound to the AAA Charles security association between the authenticator and the Charles peer in order for everything to work, so it would be more I'm not sure I'd describe the association between the peer and authenticator as an AAA association. I agree with the rest. Charles Ah, I mistyped. I meant AAA security association between Charles the authenticator and EAP server. I'd define the EAP channel binding problem as follows. There are two sets of identities that the peer and authenticator use: one at the EAP layer and one at a lower layer. There is an additional identity that the authenticator may use to authenticate to the AAA server. The channel binding problem is to make sure that the EAP server authorizes the authenticator's use of the lower layer identity to the peer and the peer's use of a given lower layer identity. In performing this authorization the EAP server must authorize that the authenticator is actually allowed to claim the lower layer identity it wants to claim. I think this is implicit -- you gave the MSK to an authenticator, therefore that authenticator's lower layer (regardless of its identity) is authorized to use that key. Of course, this assumes an authenticator has a single lower layers. I'm not sure the case of multiple lower layers been addressed. EAP could simply forbid it (i.e. one lower layer per authenticator), or say that giving a key to an authenticator authorizes it for all lower layers. In doing that it will have to make an authorization decision about whether the identity the authenticator uses to authenticate to the AAA server is authorized to claim the given lower layer identity. Currently there's no AAA mechanism for an authenticator to claim a lower-layer identity to an EAP server. Lower layer identities would have to be statically provided to the EAP server if the EAP server is going to use them for channel bindings. However that identity--between the NAS and the AAA server doesn't inherently appear anywhere else. It sounds like 802.11R does plan to expose that identity, but that's a design decision for that lower layer. I guess the point of all my commentary is that the SAP needs to be involved in your discussion of EAP channel bindings. Most cryptographically binds an L2 identities to an EAP key, and some new ones (11r) even bind AAA identities to an EAP key. If EAP channel bindings could include AAA identities, then the peer would actually have enough information to start doing identity comparisons and catch lying NASes. -- t. charles clancy, ph.d.[EMAIL PROTECTED]www.cs.umd.edu/~clancy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
On Mon, Apr 16, 2007 at 01:10:32AM -0500, Nicolas Williams wrote: - New text about EAP channel binding Actually, some of that text is incorrect -- I misunderstood the lying NAS issue: it's not about MITM attacks but about making sure that the client knows the correct name for the NAS so that it can make authorization decisions based on it (e.g., applying a specific firewall policy). I'll fix the text and re-send. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RFC 4833 on Timezone Options for DHCP
A new Request for Comments is now available in online RFC libraries. RFC 4833 Title: Timezone Options for DHCP Author: E. Lear, P. Eggert Status: Standards Track Date: April 2007 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 10 Characters: 19573 Updates:RFC2132 See-Also: I-D Tag:draft-ietf-dhc-timezone-option-05.txt URL:http://www.rfc-editor.org/rfc/rfc4833.txt Two common ways to communicate timezone information are POSIX 1003.1 timezone strings and timezone database names. This memo specifies DHCP options for each of those methods. The DHCPv4 time offset option is deprecated. [STANDARDS TRACK] This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Dialstring parameter for the Session Initiation Protocol Uniform Resource Identifier' to Proposed Standard
The IESG has approved the following document: - 'Dialstring parameter for the Session Initiation Protocol Uniform Resource Identifier ' draft-rosen-iptel-dialstring-05.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-05.txt Technical Summary This document provides a way of incorporating a dial string into the SIP or SIPS URI scheme. A dial string is a cousin of a telephone number, but rather than taking the form of a fully-qualified E.164 or national-specific telephone number, it is a description of a literal set of dialed digits that would be delivered over a POTS line. As such, it may include pauses, omit prefixes like area codes, and its applicability is necessarily restricted to a particular context (an enterprise, a LATA, etc). Support for dialstrings was formerly a feature of the tel: URI scheme specification (back in RFC2806); since that functionality did not make it into the revision (RFC3966), it is provided here specifically for the SIP and SIPS case. Working Group Summary Although this is an individual submission, it was discussed in the IPTEL WG and did not encounter any resistance. Protocol Quality This specification was reviewed for the IESG by Jon Peterson. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'A Framework for Supporting Emergency Telecommunications Services (ETS) Within a Single Administrative Domain' to Informational RFC
The IESG has approved the following document: - 'A Framework for Supporting Emergency Telecommunications Services (ETS) Within a Single Administrative Domain ' draft-ietf-ieprep-domain-frame-08.txt as an Informational RFC This document is the product of the Internet Emergency Preparedness Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-domain-frame-08.txt Technical Summary This document presents a framework discussing the role of various protocols andmechanisms that could be considered candidates for supporting Emergency Telecommunication Services (ETS) within a single administrative domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented. Working Group Summary The IEPREP WG supported the advancement of this document. Protocol Quality This document was reviewed for the IESG by Jon Peterson. Note to RFC Editor Section 3.1 OLD: A more ambitious way of supporting the mobile user is through the use of the Mobile IP (MIP) protocol. In this case and at the IP level, foreign networks introduce the concept of triangle routing and the potential for multiple access points and service context within a subnetwork. In addition, policy plays a critical role in dictating the measure of available services to the mobile user. The beaconing capability of MIP allows it to offer a measure of application transparent mobility as a mobile host (MH) moves from one subnetwork to another. However, this feature may not be available in most domains. In addition, its management requirements may discourage its widespread deployment and use. Hence, users should probably not rely on its existence, but rather may want to expect a more simpler approach based on DHCP as described above. The subject of mobile IP is discussed below in Section 4. NEW: A more ambitious way of supporting the mobile user is through the use of the Mobile IP (MIP) protocol. MIP offers a measure of application transparent mobility as a mobile host moves from one subnetwork to another while keeping the same stable IP address registered at a global anchor point. However, this feature may not always be available or in use. In any case, where it is in use, at least some of the packets destined to and from the mobile host go through the home network. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
