Subject: [Emu] draft-ietf-emu-chbind-02 and AAA interaction

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 18 Jun 2009 10:11:38 -0700

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

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Fri, 19 Jun 2009 20:39:25 -0400

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.

"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. 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). 

" 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, 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: [email-masked] [mailto:[email-masked]] On Behalf Of
Joseph Salowey (jsalowey)
Sent: Thursday, June 18, 2009 12:12 PM
To: [email-masked]
Subject: [Emu] draft-ietf-emu-chbind-02 and AAA interaction

Thanks,

Joe 
_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 22 Jun 2009 12:32:54 -0700

> From: Hoeper Katrin-QWKN37 [mailto:[email-masked]] 
> Sent: Friday, June 19, 2009 5:39 PM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: RE: [Emu] draft-ietf-emu-chbind-02 and AAA interaction
> 
> Joe,
> 
> "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 
[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 
> "4. Section 8 is about AAA validation and is not channel 
> bindings, is this section necessary?"
> 
[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
> 
> 
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joseph Salowey (jsalowey)
> 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.  
>

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Tue, 23 Jun 2009 18:11:25 -0400

Comments inline.

> From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
> Sent: Monday, June 22, 2009 2:33 PM
> To: Hoeper Katrin-QWKN37; [email-masked]
[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.

> clear to me that the EAP Server would necessarily know anything about
[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?
> is what the EAP server is dealing with it instead of the AAA server.
[KH] Agreed, this needs to be addressed-see previous comment.
> 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).
> 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.
> 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.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 23 Jun 2009 22:16:24 -0700

Hi Katrin,

Thanks for the clarifications, I think I understand better now.  

Comments inline.

> > > "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 
> 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.
> > >
> > 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?
> > 
> 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.
> 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.   

> [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.  

> > > 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.
> > 
> > > In this way no additional exchange of information is required 
> > > (again, the flow in Figure 1 is
> > > require an explicit message flow from authenticator to 
> EAP server as 
> > > part of the EAP method.
> > >
> > > 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).
> > >
> [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.  

> [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"
> > >
> > > 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
> 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.
> > >
> [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
> > >
> > >
> > >
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of Joseph Salowey (jsalowey)
> > > 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 
> > > 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.
> > > 1. In sections 5.1 and 5.2 clarify the role of message i2 with 
> > > respect to channel bindings.
> 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.
> > >

---

From: Klaas Wierenga <[email-masked]>
Date: Fri, 26 Jun 2009 15:49:13 +0200

Joe, Katrin,

A few comments

> AAA validation of the message.

yes, I agree

> 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]

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Fri, 26 Jun 2009 10:03:22 -0400

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

> From: Klaas Wierenga [mailto:[email-masked]]
> Sent: Friday, June 26, 2009 8:49 AM
> To: Joseph Salowey (jsalowey)
> Cc: Hoeper Katrin-QWKN37; [email-masked]
> Subject: Re: [Emu] draft-ietf-emu-chbind-02 and AAA interaction
> 
> Joe, Katrin,
> 
> A few comments
> 
> >>> It seems that in your picture i2 is really between the
authenticator
> >> and
> >>> other data.   My objection is restricting everything in i1 to
being
> >> AAA
> >>> looks to me like validation that should be done by the AAA
protocol.
> >> I