Re: Last call comments:draft-williams-on-channel-binding-01.txt: EAP chann
This is something that IEEE 802.11r/D5.0 is doing. R0KH-ID is set to the identity of the NAS Client (e.g., NAS-Identifier if RADIUS is used as the backend protocol) and this identifier is sent to the peer during association (before EAP authentication). In addition, both the R0KH-ID (NAS-Identifier) and R1KH-ID (authenticator MAC address) are mixed in into the key derivation after the EAP authentication. I would also add that IEEE 802.11r binds the R1KH-ID and the AP BSSID/MAC address during the post-EAP handshake. IEEE 802.11r also advertises the set of authenticators within which fast handoff is possible via the Mobility Domain IE. Currently there is no equivalent AAA attribute to carry that, but once there is (it has been discussed in RADEXT WG), it will also be possible to verify this parameter within EAP Channel Bindings. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Emu] Re: Last call comments:draft-williams-on-channel-binding-01.txt: EAP channel bindings
Yup, specifically 3280 says that a issuer, as represented by its DN will guarantee unique serial numbers within its scope and issue within its scope non-ambiguous subject DNs (e.g. no dupes). -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 1:14 PM To: Nicolas Williams Cc: Bernard Aboba; ietf@ietf.org; emu@ietf.org Subject: [Emu] Re: Last call comments:draft-williams-on-channel-binding-01.txt: EAP channel bindings Nicolas == Nicolas Williams [EMAIL PROTECTED] writes: Nicolas Also, I think my draft's definition of end-point channel Nicolas bidning needs to be tightened just a bit: not only must Nicolas the end-point IDs be cryptographically bound into the Nicolas channel, it must also be the case that the IDs Nicolas meaningfully identify the channel end-points -- that is, Nicolas that one nodes cannot assert the same ID as another Nicolas without sharing credentials with it. I think my text Nicolas implies this but does not make it sufficiently explicit. Be careful. A DN given a trust anchor seems like a find end-point identifier. However two nodes can share the same DN without sharing the same credential. Under 3280 rules either the CA issued a certificate it should not have issued or the two nodes are the same subject. That's strong enough for the channel binding to be useful even though the nodes may not share a credential. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last call comments: draft-williams-on-channel-binding-01.txt:EAP chann
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. I think you need to be careful about the precise meaning of bind and lower layer channel here. Properties of the lower layer channel such as ciphersuite negotiation are determined during the Secure Association Exchange. During the SAP other parameters advertised or negotiated between the peer and authenticator can be cryptographically bound to the transient session keys used between peer and authenticator. For example, within IEEE 802.11i, the peer and authenticator MAC address, ciphersuite and capabilities are securely confirmed during the 4-way handshake. In contrast, Channel Bindings as defined in RFC 3748 occur during the EAP exchange. Its purpose is to confirm the consistency of channel properties advertised by the authenticator to the peer and EAP server. However, negotiation of the lower layer channel properties occurs during the SAP. Specific details 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. Secure Association Protocols are specified in considerable detail within IEEE 802.11i, IEEE 802.16e and IKEv2. Also, both RFC 3748 and the EAP Key Management Framework discuss Channel Bindings. So saying it is unspecified doesn't seem accurate. The endpoint channel bindings would be defined for the specific lower layer. EAP Channel Bindings can be supported by an EAP method today without any modification to lower layer specifications, so I don't think this is correct. EAP also has a facility called cryptographic binding, which is another instance of channel binding. Cryptographic binding as defined in RFC 3748 is used to demonstrate that the endpoints of the EAP exchange participated in all portions of that exchange. This does not relate to lower layer channel properties, per se. Cryptographic binding refers to binding the channel created by a tunneling EAP method to an inner authentication performed within that method. This is correct. Cryptographic binding will likely use unique channel bindings. Cryptographic binding doesn't ensure that the authenticator provides the same information to both the peer and server, so that it doesn't address the Channel Binding problem. Do these changes make sense to people? Am I telling any lies or conflating two architectures in a bad way? In general, the changes are potentially confusing, but I do think that it would be worthwhile to continue to work on improving the text. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt
O, I definitely think they are session keys. [BA] They are not TSKs according to the definition in the EAP Key Management Framework. Wait, what's wrong with giving 100 authenticators 100 different keys provided that each authenticator is authorized to claim the identity it plans to claim? Isn't that exactly the sort of thing we do want to do? [BA] The creation of cryptographically separate keys for each authenticator is not sufficient; the EAP Key Management Framework describes the problems that can result without authentication and authorization. As an example, Proactive Key Distribution as proposed in http://www.watersprings.org/pub/id/draft-irtf-rch-handoff-04.txt distributes keys in advance of peer arrival at an authenticator. The problem is that evidence is not provided to the AAA server that the peer actually arrived at an authenticator to whom a proactive key was provided. Since accounting records can now be created without a corresponding AAA conversation, new classes of attacks become possible. For example, a rogue authenticator can claim that the authenticator has connected to itself or another authenticator in the neighbor graph by issuing bogus accounting records. Since Bogus accounting records can be created without fear of detection, financial fraud becomes possible. Corruption of the neighbor graph is also possible unless the AAA server only creates neighbor graph entries in response to successful authentications between the peer and AAA server. Without this, a rogue authenticator could corrupt the neighbor graph by submitting bogus accounting records, causing proactive keys to be distributed outside their authorized scope (e.g. only to legitimate 'neighbors'). Note that proactive key distribution actually provides more security safeguards than some other 'fast handoff' proposals because the creation of a neighbor graph based on successful authentications limits the scope of potential mischief. For example, an authenticator in Hawaii cannot claim to be a neighbor of one in New York without providing evidence that a peer had actually authenticated via both. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Dean: I'm still not clear on a few things: -- When did Russ Housley learn of the Patent Filing? I was aware that Mark Brown was working on a patent; however, I did not begin working with him until after his provisional patent application was filed. I did not see the claims until the filing became public. Since I knew that a patent was in the works, but I did not know the details, at the time we submitted the -00 draft to the repository (which was February 2006), I reminded Mark Brown that an IPR statement might be necessary. Russ ___ 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 Sat, Apr 07, 2007 at 04:44:54PM -0400, Charles Clancy wrote: This is one of the fundamental issues with EAP channel bindings. The NAS ID is bound to the AAA security association between the authenticator and the EAP server. The MAC address is visible to the client. Thus the peer and EAP server each know a different identity for the authenticator. Whatever identity is used must be channel-bound to the AAA security association, otherwise the authenticator could lie to the EAP server about its identity. I see two solutions: 1. The NAS ID is broadcast to the peer before EAP authentication (e.g. in an 802.11 beacon) This is something that IEEE 802.11r/D5.0 is doing. R0KH-ID is set to the identity of the NAS Client (e.g., NAS-Identifier if RADIUS is used as the backend protocol) and this identifier is sent to the peer during association (before EAP authentication). In addition, both the R0KH-ID (NAS-Identifier) and R1KH-ID (authenticator MAC address) are mixed in into the key derivation after the EAP authentication. -- Jouni MalinenPGP id EFC895FA ___ 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
to be an L2 identity. It can be any identity that's meaningful to the parties involved, and can serve as the basis for making authorization decisions. As long as it's cryptographically bound to the L2 channel and that channel provides suitable protection for the EAP method doing the EAP channel binding, THEN Sam's observation is correct: EAP channel binding uses what I termed end-point channel binding and EAP cryptographic binding uses what I termed unique channel binding. I don't think I'm convinced that EAP channel bindings are doing this binding to the L2 channel. The identity used in an EAP channel binding must be bound to the AAA security association between the authenticator and the peer in order for everything to work, so it would be more likely a NAS-ID than a MAC address. That's not to say there isn't an L2 binding happening -- but I think it's being performed by the L2 secure association phase that uses the EAP key to derive L2 keys. Then during that handshake, a MAC address may be involved, binding in an L2 identity. I guess I see EAP channel bindings as an EAP-AAA binding, and the L2 secure association protocol as the EAP-L2 binding. -- 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
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. Ah, I mistyped. I meant AAA security association between the authenticator and EAP server. Charles likely a NAS-ID than a MAC address. Are you sure that the binding happens between the mac address and NAS ID? I don't understand how the peer ever confirms the NAS ID at layer two unless it also happens to be a MAC address. This is one of the fundamental issues with EAP channel bindings. The NAS ID is bound to the AAA security association between the authenticator and the EAP server. The MAC address is visible to the client. Thus the peer and EAP server each know a different identity for the authenticator. Whatever identity is used must be channel-bound to the AAA security association, otherwise the authenticator could lie to the EAP server about its identity. I see two solutions: 1. The NAS ID is broadcast to the peer before EAP authentication (e.g. in an 802.11 beacon) 2. The EAP server maintains a static mapping between NAS IDs and MAC addresses, manually binding MAC addresses to AAA security associations I do agree with you though that EAP channel bindings include the peer's lower layer identity and the identity of the authenticator that the peer will later be able to verify. Right -- but there needs to be some way for the EAP server to know the authenticator's lower-layer information in such a way that the authenticator can't lie about its lower-layer information to the EAP server. Charles I guess I see EAP channel bindings as an EAP-AAA Charles binding, and the L2 secure association protocol as the Charles EAP-L2 binding. The L2 secure association protocol cannot be an eap-anything binding: it does not typically use EAP level identifiers. It uses EAP keys though. If from a higher layer we know EAP keys could have only been delivered to a particular EAP/AAA identity, and those keys are exported to the lower layer, then I'd think you have a binding from the EAP identity to the EAP keys to the lower-layer keys to the lower-layer identity. -- 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
Sam, In skimming through Nico's draft, it looks like EAP's crypto bindings look something like GSS channel bindings. EAP's channel bindings, on the other hand, don't really look like GSS channel bindings. In order for EAP's channel binding to look like GSS channel binding, EAP channel binding would have to cryptographically bind an L2 security association to EAP keys -- but that's not what it's doing. It's binding L2 identities to EAP keys. In fact, there's no reason it has to be an L2 identity. It can be any identity that's meaningful to the parties involved, and can serve as the basis for making authorization decisions. Perhaps you could abstract the definition of channel bindings even further such that all three are subsets of some common terminology... but that sounds painful. -- t. charles clancy, ph.d.[EMAIL PROTECTED]www.cs.umd.edu/~clancy On Fri, April 6, 2007 1:43 pm, 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 Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt
Bernard O, I definitely think they are session keys. [BA] They Bernard are not TSKs according to the definition in the EAP Key Bernard Management Framework. That's true. But that definition is not normative for draft-housley-aaa-key-mgmt. [BA] If the documents are using a different definition of session keys then I think we need to make sure that the term is clearly defined in draft-housley to avoid confusion. Again, I think that correctness of accounting in this instance is an additional requirement the key management framework puts on top of draft-housley-aaa-key-mgmt. [BA] The term AAA stands for authentication, authorization and accounting. Why would the correctness of accounting data be a requirement only for one particular AAA usage? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Dean: I always recuse myself from IESG evaluation of a document for which I am an author. You will find this to be the normal practice for all IESG members. I have no financial interest in PedPhone Security or the patent filing. I provided consulting services to RedPhone Security; it was a simple work for hire. I have no investors in my very small consulting company: Vigil Security, LLC. I am the owner, and I am the only full-time employee. Russ ItAt 07:47 PM 4/7/2007, Dean Anderson wrote: On Fri, 6 Apr 2007, Russ Housley wrote: Dean: I'm still not clear on a few things: -- When did Russ Housley learn of the Patent Filing? I was aware that Mark Brown was working on a patent; however, I did not begin working with him until after his provisional patent application was filed. I did not see the claims until the filing became public. Since I knew that a patent was in the works, but I did not know the details, at the time we submitted the -00 draft to the repository (which was February 2006), I reminded Mark Brown that an IPR statement might be necessary. How long did it take to produce the draft? Presumably, you must have started working on the project earlier than the date of submission. Did you know of the patent application before submission? I note that you recused yourself from the decisions made on this draft. That is commendable. It also implies that you stand to benefit somehow from the draft. But the patent (assuming it is granted) gives Brown and Wilke a monopoly on the technology. How is it, in general terms, that you will benefit from this draft? Do you have, perhaps, a favorable license agreement with Brown? Perhaps stock in Brown's company? Did Brown agree to invest in your company? Is there another patent application? As it stands, the information we have, indicates that only Brown stands to benefit, and this doesn't explain your involvement in these drafts. Some clarity on how you stand to benefit would be helpful. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: In support of symbolic references
-Original Message- From: Jari Arkko [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 9:13 AM To: Simon Josefsson Cc: Sam Hartman; ietf@ietf.org; Steven M. Bellovin Subject: Re: In support of symbolic references Simon, Maybe we can lobby for it to become the default. +1 (I think it would be the right default, even if I agree with John Klensin's concern.) Jari Same here. I used symbolic references in all documents I authored or co-authored recently and I have expressed my preference for symbolic references in many reviews I performed in the past, although I was missing grounds to make this a very strong recommendation. Dan ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Todd: This is a follow-on note. Did you miss the earlier one, where I said: I was aware that Mark Brown was working on a patent; however, I did not begin working with him until after his provisional patent application was filed. I did not see the claims until the filing became public. Since I knew that a patent was in the works, but I did not know the details, at the time we submitted the -00 draft to the repository (which was February 2006), I reminded Mark Brown that an IPR statement might be necessary. Without seeing the claims, I could not know whether or not an IPR statement was required. Thus, the reminder to my coauthor was the appropriate action on my part. Russ At 12:23 PM 4/9/2007, todd glassey wrote: Russ - this isn't about Financial Interests its about the need to formally disclose something that you are uniquely aware of that the rest of the IETF isn't. That makes you liable IMHO for any damages someone suffers because of this failure to disclose. And since you are a IETF Manager its worse. Todd Glassey - Original Message - From: Russ Housley [EMAIL PROTECTED] To: Dean Anderson [EMAIL PROTECTED] Cc: Mark Brown [EMAIL PROTECTED]; ietf@ietf.org; iesg@ietf.org Sent: Monday, April 09, 2007 6:35 AM Subject: RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns Dean: I always recuse myself from IESG evaluation of a document for which I am an author. You will find this to be the normal practice for all IESG members. I have no financial interest in PedPhone Security or the patent filing. I provided consulting services to RedPhone Security; it was a simple work for hire. I have no investors in my very small consulting company: Vigil Security, LLC. I am the owner, and I am the only full-time employee. Russ ItAt 07:47 PM 4/7/2007, Dean Anderson wrote: On Fri, 6 Apr 2007, Russ Housley wrote: Dean: I'm still not clear on a few things: -- When did Russ Housley learn of the Patent Filing? I was aware that Mark Brown was working on a patent; however, I did not begin working with him until after his provisional patent application was filed. I did not see the claims until the filing became public. Since I knew that a patent was in the works, but I did not know the details, at the time we submitted the -00 draft to the repository (which was February 2006), I reminded Mark Brown that an IPR statement might be necessary. How long did it take to produce the draft? Presumably, you must have started working on the project earlier than the date of submission. Did you know of the patent application before submission? I note that you recused yourself from the decisions made on this draft. That is commendable. It also implies that you stand to benefit somehow from the draft. But the patent (assuming it is granted) gives Brown and Wilke a monopoly on the technology. How is it, in general terms, that you will benefit from this draft? Do you have, perhaps, a favorable license agreement with Brown? Perhaps stock in Brown's company? Did Brown agree to invest in your company? Is there another patent application? As it stands, the information we have, indicates that only Brown stands to benefit, and this doesn't explain your involvement in these drafts. Some clarity on how you stand to benefit would be helpful. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
problems with I-D submissions
Would it be possible for the people who process I-D submissions to provide helpful error reports when bouncing a submission? Whenever I ask for clarification from them they just repeat the same unhelpful error message or close the ticket and ignore my emails. For example, draft-fanf-smtp-quickstart-00 was bounced because I needed to give my draft a proper file name - despite the fact that it used exactly the same form as draft-fanf-smtp-rfc1845bis-00 which was published without difficulty. It eventually transpired that they didn't think my initials (fanf) were related to the name of one of the authors in some way, but rather than explaining this they repeatedly told me to re-read the guidelines. Another example: Owing to a lurking obsolete version of xml2rfc, I managed to produce two versions of -quickstart-01, one with an Internet Society copyright and one with an IETF Trust copyright. When I submitted the wrong one it was bounced with a message telling me I hadn't included the boilerplate. Of course I had included the boilerplate, just the wrong version. It would have saved me a lot of time and irritation failing to spot differences in seemingly identical documents if they had said I had out-of-date boilerplate. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ LUNDY FASTNET: WEST OR NORTHWEST BECOMING VARIABLE 2 OR 3, OCCASIONALLY 4. SLIGHT OR MODERATE. MAINLY FAIR. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last call comments: draft-williams-on-channel-binding-01.txt:EAP chann
Bernard == Bernard Aboba [EMAIL PROTECTED] writes: 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. Bernard I think you need to be careful about the precise meaning Bernard of bind and lower layer channel here. I'm using them consistently with the rest of the document. Bernard Properties of the lower layer channel such as ciphersuite Bernard negotiation are determined during the Secure Association Bernard Exchange. During the SAP other parameters advertised or Bernard negotiated between the peer and authenticator can be Bernard cryptographically bound to the transient session keys Bernard used between peer and authenticator. For example, within Bernard IEEE 802.11i, the peer and authenticator MAC address, Bernard ciphersuite and capabilities are securely confirmed Bernard during the 4-way handshake. This is a true statement. Bernard In contrast, Channel Bindings as defined in RFC 3748 Bernard occur during the EAP exchange. Its purpose is to confirm Bernard the consistency of channel properties advertised by the Bernard authenticator to the peer and EAP server. However, Bernard negotiation of the lower layer channel properties occurs Bernard during the SAP. Understood and I believe that to be consistent with my text. Specific details 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. Bernard Secure Association Protocols are specified in Bernard considerable detail within IEEE 802.11i, IEEE 802.16e and Bernard IKEv2. Also, both RFC 3748 and the EAP Key Management Bernard Framework discuss Channel Bindings. So saying it is Bernard unspecified doesn't seem accurate. No one has defined the format of channel bindings and with the possible exception of 802.11r I don't know of any lower layer that has clearly defined what identity should be bound for that layer. The endpoint channel bindings would be defined for the specific lower layer. Bernard EAP Channel Bindings can be supported by an EAP method Bernard today without any modification to lower layer Bernard specifications, so I don't think this is correct. How do I know what the lower layer identity is unless the lower layer spec tells me EAP also has a facility called cryptographic binding, which is another instance of channel binding. Bernard Cryptographic binding as defined in RFC 3748 is used to Bernard demonstrate that the endpoints of the EAP exchange Bernard participated in all portions of that exchange. This does Bernard not relate to lower layer channel properties, per se. I did not claim that cryptographic binding was related to lower layer channel properties in EAP's sense of lower layer. Cryptographic binding refers to binding the channel created by a tunneling EAP method to an inner authentication performed within that method. Bernard This is correct. Cryptographic binding will likely use unique channel bindings. Bernard Cryptographic binding doesn't ensure that the Bernard authenticator provides the same information to both the Bernard peer and server, so that it doesn't address the Channel Bernard Binding problem. This is a true statement; as best I can tell it is unrelated to anything I've said. ___ 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
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. 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. 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last call comments: draft-williams-on-channel-binding-01.txt:EAP chann
So then the stuff to bind to exists but no spec says the EAP channel bindings for this kind of L2 association is XYZ and we all have a good idea of what that text should read like, right? On Mon, Apr 09, 2007 at 03:52:31PM -0700, Bernard Aboba wrote: No one has defined the format of channel bindings and with the possible exception of 802.11r I don't know of any lower layer that has clearly defined what identity should be bound for that layer. [BA] As outlined in RFC 3748 and the EAP Key Management Framework, channel binding matching is designed to be a mechanical process, which implies that they are communicated in the form of AAA attributes. For example, the following AAA attributes can be sent from the NAS to the AAA server for IEEE 802: Called-Station-Id: Authenticator Port MAC address or AP BSSID (potentially with the SSID) Calling-Station-Id: Supplcant MAC address NAS-Identifier: Authenticator identifier (IEEE 802.11r R1KH-ID) How do I know what the lower layer identity is unless the lower layer spec tells me Lower layer specifications already define the source MAC addresses (e.g. IEEE 802), and in some cases, authenticator identities (IEEE 802.11r). So no additional lower layer standards are required. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Russ == Russ Housley [EMAIL PROTECTED] writes: Russ Dean: I always recuse myself from IESG evaluation of a Russ document for which I am an author. You will find this to be Russ the normal practice for all IESG members. Russ, Dean, Todd and others. Might I suggest that this part of this discussion has outlived its useful life on the ietf list. I'd like to thank all those who have participated for helping us understand what happened and for expressing their opinions. However, at this point, people seemed happy with taking the draft to the TLS working group. The authors asked for a week delay while they prepared a new IPR disclosure. That disclosure seems to have hit the IETF servers, so I'll touch back with the authors and then engage the TLS chairs. I'd like to suggest that discussions of what Russ should or should not have done,rehashing the facts of the situation yet again,and comments about specific legal obligations the IETF or its participants may or may not have with regard to this situation are not benefitting the ietf list. Thanks, Sam Hartman Security Area Director ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)' to Proposed Standard
The IESG has approved the following document: - 'Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs) ' draft-bagnulo-multiple-hash-cga-03.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 Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bagnulo-multiple-hash-cga-03.txt Technical Summary This document analyzes the implications of recent attacks on commonly used one-way hash functions on Cryptographically Generated Addresses (CGAs) and updates RFC 3972 to support multiple hash algorithms. An IANA registry is established to register hash functions for CGAs. Working Group Summary This document is not the result of any IETF Working Group. Protocol Quality The protocol is designed to future-proof CGAs against attacks that have not yet occurred. This document was reviewed by Russ Housley for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Link-layer Event Notifications for Detecting Network Attachments' to Informational RFC
The IESG has approved the following document: - 'Link-layer Event Notifications for Detecting Network Attachments ' draft-ietf-dna-link-information-06.txt as an Informational RFC This document is the product of the Detecting Network Attachment Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-link-information-06.txt Technical Summary Certain network access technologies are capable of providing various link-layer status information to IP. Link-layer event notifications can help IP expeditiously detect configuration changes. This document provides a non-exhaustive catalogue of information available from well-known access technologies. Working Group Summary The dna working group reached consensus on this document on the DNA mailing list. There was strong support for the document from key contributors to the WG and no opposition. One contentious issue in this draft has been whether it should document just Link Up or also Link Down events. Based on reviews from the designer of DNAv4 and the AD review, it was finally decided to focus only on the Link Up event. Protocol Quality This document and has been reviewed by the dna working group and the required changes have been incorporated into the document. The document has also been reviewed by a member of the IAB (Bernard Aboba) and wg chairs of the bridgeand hubmib working groups (Dan Romascanu and David Harrington). Some of the information contained within has been derived from documents reviewed by other standards bodies. A significant amount of review was also received during IETF Last Call, and the suggested changes are either in the -06 version or in the below RFC Editor notes. Note to RFC Editor Please insert a new paragraph between the 2nd and 3rd paragraph of Section 1: OLD: NEW: Link-layer event notifications can help IP expeditiously detect configuration changes. This document provides a non-exhaustive catalog of information available from some access technologies, and discusses the interpretation of this information at the IP layer. This document is not intended to specify or change the behaviour of these access technologies in any manner. Also, please change the following. In Section 3: OLD: notification must be delivered NEW: notification is delivered OLD: notification must be generated and what information must be included in it NEW: notification is generated and what information is included in it Section 3.1: OLD: must generate a link up NEW: generates a link up OLD: notification must be the IPv4 NEW: notification is the IPv4 Section 3.2: OLD: notification must be delivered NEW: notification is delivered OLD: address must be provided NEW: address is provided Section 3.3: OLD: must be generated NEW: is generated OLD: must cause a link up NEW: causes a link up OLD: notification must be generated, if one NEW: notification is generated, if one OLD: notification must be generated. NEW: notification is generated. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
