> -----Original Message----- > From: Hoeper Katrin-QWKN37 [mailto:khoe...@motorola.com] > Sent: Friday, June 19, 2009 5:39 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] draft-ietf-emu-chbind-02 and AAA interaction > > Joe, > > Thank you for bringing this up. Find my replies below: > > "1. In sections 5.1 and 5.2 clarify the role of message i2 > with respect to channel bindings." > > [KH] I agree with your observations that the use and exchange > of i2 is not well described in the draft and needs to be clarified. > > The EAP server can utilize three pieces of information for > its channel binding verification, namely: i1 received from > the EAP peer, i2 received as part of AAA communications with > the authenticator and i3 stored in a local database. The > confusion lies in the description of i2 and its "exchange". > > i2 is basically information that the EAP server already > "knows" about the authenticator. The information is *not* > sent as payload to the EAP server, it was rather part of > previous communications with the authenticator during the > current EAP session. For example, the EAP server typically > "knows" the NAS-IP address of the authenticator in an EAP > execution. Basically, we want to utilize information for the > channel binding consistency check that the EAP server already > knows about the authenticator. This information is referred to as i2. > > I agree that the arrow with i2 from authenticator to EAP > server in Figure 1 is wrong, because i2 is not a protocol > message. Figure 1 does not reflect the above description and > needs to be revised accordingly. > On the other hand, an EAP server can optionally include i2 in > its reply to the EAP peer, e.g. to enable the peer to perform > its own consistency checks. In that case, i2 needs to be > explicitly exchanged. > [Joe] OK, I think I may understand better. If I understand correctly, there are two separate consistency checks:
1. one checking the consistency of what the client sees against a database of what should be seen. (i1) 2. one checking the consistency of what the authenticator against a database of what should be seen. (i2) Is this correct? It seems that in your picture i2 is really between the authenticator and AAA. This affects some of your statements above. For example its not clear to me that the EAP Server would necessarily know anything about NAS-IP. > "2. In section 6.1 define channel binding data as a superset > of AAA attributes. In particular the last paragraph needs > work and seems inconsistent with 7.1 which allows for the > inclusion of Diameter attributes without the exclusion of > other attributes." > > [KH] The reason why we chose i2 as AAA data is because the > authenticator and EAP server communicate using an AAA > protocol during an EAP execution. Hence, the EAP server has > access to AAA attributes of the authenticator in its role as > AAA client. [Joe] So I think it makes sense that i2 is AAA data, what I'm not seeing is what the EAP server is dealing with it instead of the AAA server. > In this way no additional exchange of information > is required (again, the flow in Figure 1 is > wrong) and i2 does not need to be explicitly exchanged. This > is important because we want to be able to add channel > binding to EAP methods without modifying the method's > protocol flow. If we would allow > i2 to be any type of data about the authenticator, this would > require an explicit message flow from authenticator to EAP > server as part of the EAP method. > > To avoid the introduction of additional communication flows, > the modification of EAP methods and potentially the > involvement of other protocols, I argue that i2 should only > contain AAA information about the authenticator. Any other > type of information about the authenticator that seems > desirable for the channel binding verification can be stored > in the local database (i3). > [Joe] I'm fine with i2 containing AAA information, but I don't really see how it is part of EAP channel bindings. This seems to be more about validating information in the AAA protocol. For channel bindings I am more concerned with what is communicated in i1. This is what EAP methods need to carry. i1 may need to carry some data that may also be in a AAA attribute, but it may also need to carry other data. My objection is restricting everything in i1 to being AAA data. The current draft seems to requirements for i1 and i2 all together. I don't think this is correct. > > " Sections 7.1, 7.2, 7.3 only recommend comparing information > with what is received from the NAS and not about comparing > with local information" > > [KH] Section 7 describes which attributes can be used in i1 > for the channel binding compliance check, and Section 8 the > attributes that can be used as part of i2. Comparing local > information is only described as text in Section 10.1. We > cannot provide concrete attributes here because > i3 is protocol-independent and basically contains data > derived from policies. I don't think we can provide concrete > examples here, but it might be a good idea to add another > section after 7 and 8, to generally outline how the > comparison with the local information should be executed. In > that case, Section 10 could remain the same, explaining how > such a database can be set up. > > "4. Section 8 is about AAA validation and is not channel > bindings, is this section necessary?" > > [KH] Disagree, see my comments to your suggestions #2. > [Joe] So, I see i1 as the messages used in EAP channel bindings. i2 looks to me like validation that should be done by the AAA protocol. I think I may not have understood your points above. I think the draft needs to focus more on the requirements of i1 exchange and less on the requirements of the i2 exchange. > > Joe, I hope I could clarify some of your issues. I would also > like to hear other opinions from the list on these issues. > > Katrin > > > > -----Original Message----- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On > Behalf Of Joseph Salowey (jsalowey) > Sent: Thursday, June 18, 2009 12:12 PM > To: emu@ietf.org > Subject: [Emu] draft-ietf-emu-chbind-02 and AAA interaction > > After reviewing recent comments from Klaas on the list on > Channel bindings there is one issue I would like to try to > resolve before bringing this draft to last call. > > In section 5.1, the draft defines a message i2, which is the > message carrying AAA attributes from the authenticator to the > server using a AAA protocol. While, this message does occur > in the protocol interactions, it is actually not that > important in the channel binding interactions because the > server does not completely trust the authenticator and must > know what is valid through some other mechanism, such as the > local database defined in the draft. I think this section is > a bit misleading and needs to emphasize this point. This is > further confused by the fact that in some sections the draft > focuses entirely on AAA attributes to carry channel-binding > information. While AAA attributes are undoubtedly important > to carry it does not appear that they should be the only type > of data allowed especially since the AAA protocol is not > required to be directly involved other than to carry EAP. > This is demonstrated by the "TODO" 7.3 which suggests we need > to add a way to carry the 802.11 RSN-IE. Since AAA protocols > haven't needed to carry this information to date, it is not > clear that adding this information to them would be helpful. > Given this I would suggest the following modifications to the > draft: > > 1. In sections 5.1 and 5.2 clarify the role of message i2 > with respect to channel bindings. > 2. In section 6.1 define channel binding data as a superset > of AAA attributes. In particular the last paragraph needs > work and seems inconsistent with 7.1 which allows for the > inclusion of Diameter attributes without the exclusion of > other attributes. > 3. Sections 7.1, 7.2, 7.3 only recommend comparing > information with what is received from the NAS and not about > comparing with local information 4. Section 8 is about AAA > validation and is not channel bindings, is this section necessary? > > If the working group agrees with this direction I can provide > text for the changes. > > Please send comments to the list. > > Thanks, > > Joe > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
