Klaas, Thanks for your feedback. Joe and I are currently working on a revision that will hopefully address all issues raised by Joe and you.
Regards, Katrin > -----Original Message----- > From: Klaas Wierenga [mailto:kl...@wierenga.net] > Sent: Friday, June 26, 2009 8:49 AM > To: Joseph Salowey (jsalowey) > Cc: Hoeper Katrin-QWKN37; emu@ietf.org > Subject: Re: [Emu] draft-ietf-emu-chbind-02 and AAA interaction > > Joe, Katrin, > > A few comments > > > Thanks for the clarifications, I think I understand better now. > > > > Comments inline. > > > > > >>>> 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? > >>> > >> [KH] Almost. Check 1 "is the authenticator lying to the peer?": > >> consistency check of i1 and i2 with the aid of the database > >> (because a direct comparison is not possible), i.e. checking > >> whether the info submitted to the peer and known to by the > >> EAP server are consistent. > >> Check 2 "is the authenticator lying to both ends to violate rules": > >> check whether i1 and i2 comply with policies stored in the database. > >> Actually check 2 could be split into two checks: 2a) check > >> whether authenticator lies to the EAP server and 2b) does the > >> authenticator violate any rules. > >> > > [Joe] Good point, so 2A would be useful in the case where the AAA is > > making some policy decision based on what the authenticator states and > > there is more than one choice for the authenticator. Perhaps if the > > authenticator can advertise a free and charged SSID the client > > associates with the free one, but the authenticator reports the > > charged > > one. This may be a bit contrived, but it seems like it could be a > > good > > thing to do. I think it would be useful to split this up into 2A and > > 2B. 2A is needed when there is an attribute used in AAA policy that > > the > > client is aware of and there is more than one choice for the value of > > the attribute for the authenticator. 2B I think is something more for > > AAA validation of the message. > > yes, I agree > > > > > > >>> 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. > >> [KH] This is true and needs to be clarified. Either the EAP > >> server can only use the AAA attributes it knows about the > >> authenticator from the on-going EAP execution or the EAP > >> server needs to get this information from the AAA server to > >> perform the consistency check. Do you see any use case for the > >> former? > > > > [Joe] So, I think some of the data, mostly 2B data, should be > > validated > > by the AAA server. Some of the type 1 data may not be passed in the > > AAA > > protocol. For 1 and 2A data that is communicated in AAA I think it > > will > > depend upon implementation as to who maintains the authoritative > > database for attributes. In some cases validation responsibility > > may be > > split. > > > >>> > >>>> "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. > >> [KH] Agreed, this needs to be addressed-see previous comment. > >>> > >>>> 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. > >> [KH] I believe this is the only way to check whether an > >> authenticator is lying about its identity, i.e. the > >> identifier& addresses broadcasted to peers and identifiers & > >> addresses used in the backend network. Again these > >> identifiers & addresses may be of different types but should > >> nevertheless map to the same device (check via a lookup in > >> the database). > > [Joe] I'm not sure how much of this information is useful or > > practically > > verifiable by the EAP server. For example, often the client has no > > idea > > of the NAS IP address and may not have an idea of the NAS-ID. In many > > cases I'm not sure if spoofing addresses is a problem or if this is > > very > > manageable to maintain this information. If we split the data into > > i2a > > and i2b it may be clearer. > > I guess we shouldn't make assumptions as to what information is useful > or practically verifiable. I think the bottom line is that the EAP- > server learns a whole bunch of things, some of which may be verifiable > in a particular environment and others are not. For example in the > case of RadSec the EAP-server may know with some certainty what the ID > of the NAS is and in other circumstances not. But splitting i2a and > i2b would make things clearer. > > Klaas > > [no comments below here] > > > > >>> > >>> 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. > >>> > >> [KH] Agreed. This limitation of i1 was not intended and needs > >> to be addressed. i1 can contain anything that was broadcasted > >> in the authenticator's (NAS) beacon while i2 is restricted to > >> AAA attributes. > >>>> > >>>> " 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. > >> > >> [KH] In order to detect whether an authenticator is "lying" > >> you need some data to compare i1 too. We believe that lying > >> can be detected by comparing the views the EAP peer and EAP > >> server have about the authenticator in an EAP session. The > >> database is needed to enable the comparison. In addition, we > >> check for the case that the authenticator lies to both ends > >> (i.e. to the EAP peer and the EAP server) by checking the > >> compliance of i1 and i2 with the policies stored in the database. > > > > [Joe] OK, so some i1 data can be compared with i2, in particular i2A > > data that has various options that affect policy evaluation. In > > general > > all i1 and i2 data that is important to the system should be checked > > against some authoritative database. > > > >>> > >>>> > >>>> 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
