Subject: [Emu] Review of draft-clancy-emu-chbind-00

From: Bernard Aboba <[email-masked]>
Date: Mon, 23 Jun 2008 23:02:44 -0700

Overview I have read this document and have found several major issues with it.  As a result,I don't think it is currently suitable for adoption of an EMU WG work item.  Issues:  a. Mistatement of the 'Lying NAS' problem.   The 'Lying NAS' problem does not just concern the issue of whether the authenticatorgives different information to the peer and the server;  it also relates to the ability of the server to verify that the information is actually correct.  The document does not refer to the necessity of first-hop verification of the information provided by the authenticator, such as the mapping between theNAS-Identification attributes and the source address.   The need for verification impacts the trust model in some major ways, sincenot only does the authentication server need to trust that the authenticatorattributes have not been modified along the path -- it also needs to trust thatthe first hop was configured to check the validity of attributes that only it cancheck.   For example, it's not much help for the AAA Server to verify that the RSN IEprovided to the STA is the same one it got from the AP if there is no way ofverifying whether the AP actually was configured to emit that RSN IE.  b. Lack of applicability to the roaming case.  The document states that Channel Bindings only apply to the non-roaming case. I'm not sure why this restriction is mentioned because the issue of verificationis present even within a single domain.   c. Discussion of 'fuzzy' comparisions.  By their nature, Channel Bindings may includeinformation that may be opaque to the AAA server, such as the RSN IE.  Given thatthe AAA server may not be capable of understanding the contents of the attributes,I question whether the concept of 'fuzzy comparisons' makes sense.  Rather, I thinkwe need to assume that a AAA server will probably only be capable of 'byte by byte'comparisons in most cases.  This is an important issue, because it affects the structureof data that needs to be provided by the client, and avoid potential 'canonicalization'issues that could greatly complicate the successful implementation of channel bindings.  d. Discussion of lower layer channel bindings.  The document does not discuss the potential use of channel bindings in lower layers suchas IEEE 802.11r.  I think that this is important since lower layers such as 11r do bind EAPkeying material to lower layer parameters (such as the peer and authenticator MAC address). Thus, lower layer channel bindings is an alternative that should be discussed.  e. Development of requirements.  If this document is going to include an evaluation ofalternative approaches, then it needs to clearly articulate the requirements for such anevaluation.  f. Clear distinction between RFC 5056 and 3748 channel binding concepts.  The currentdocument is not as clear as it could be on this.  The RFC 5056 channel binding conceptis closer to that of 'cryptographic binding' than it is to EAP channel bindings.  This shouldbe made clear.  g. Exploration of operations implications.  There are a number of barriers to successfulimplementation of channel bindings that need to be explored, including: 1. Required configuration for first-hop AAA clients. 2. Potential changes to drivers and AAA servers. 3. Potential impacts on authentication reliability.  h. Motivation.  Why should we care about Channel Bindings?  Given the operational costsI'd suggest that the document needs to make a case that there is a potentially serioussecurity vulnerability here.  Such a case probably involves some kind of financial fraudissue which is most likely in a roaming situation - which is unfortunately a scenario that thedocument rules out of scope.   Some specific comments.  ============================ Abstract   This document defines how to implement channel bindings for   Extensible Authentication Protocol (EAP) methods. [BA] I'd add a definition of the problem to the abstract goals.  Section 1   A well-documented problem with the current Extensible Authentication   Protocol (EAP) architecture [RFC3748] when used in pass-through   authenticator mode is the so-called 'lying NAS' problem.  Here, a   Network Access Server (NAS), or pass-through authenticator, may   authenticate to the backend AAA infrastructure using one set of   credentials, while representing contrary information to EAP clients. [BA] The 'lying NAS' problem is not really about credentials, since in RADIUS the identity of a RADIUS client is defined by its IP address.Rather, the issue is providing different *information* (e.g.Called-Station-Id, NAS-Identifier, etc.) to the peer and AAA server.     A concrete example of this may be an IEEE 802.11 access point with a   security association to a particular AAA server.  While there may be   some identity tied to that security association, there's no reason   the access point need advertise the same identity to clients.   [BA] The identity used in the AAA server security association and theone advertised to clients do not necessary have to agree, even if theNAS is not lying.     In   fact, it may include whatever information in its beacons (to include   different SSID or security properties) it desires.  This could lead   to situations where, for example, a client joins one network that's   masquerading as another. [BA] The SSID is a good example, but the 'security properties' (e.g. RSN IE)are not provided to the AAA server.  Therefore it isnot possible for a NAS to 'lie' to the AAA server about the RSN IE itsent in a Beacon.    Channel bindings [RFC5056] seek to enforce a stronger security   relationship between the three entities, by allowing the client and   server to compare their relative perception of the authenticator's   identity in a secure channel.  [BA] RFC 5056 specifically states that it does not apply to EAP, andthat the use of the term 'Channel Bindings' is not the same as theone used in EAP.  As a result, I'd recommend deleting the aboveparagraph or clarifying the relationship.     This document defines how to use 'AAA   Payloads' [I-D.clancy-emu-aaapay] within EAP methods to implement   channel bindings.  Unlike [RFC5056], channel binding in EAP context   does not ensure binding different layers of a session but rather the   information advertized to client and authentication server by an   authenticator acting as pass-through device during an EAP session. [BA] You might say that 'Channel Bindings' in RFC 5056 corresponds tothe term 'cryptographic binding' in EAP.     It is preferable to use this idea, rather than hashing identity   information directly into keys, for a number of reasons:   o  It allows for fuzzy comparisons of entity names, rather than      requiring absolute.  This can facilitate deployment and debugging. [BA] Not sure this is convincing because it's doubtful whether'fuzzy comparisons' are implementable in the alternative approach either. Wouldn't this require the AAA server to be able to parse the attributesand 'understand' them in some deep manner?     o  Any EAP method that provides mutual authentication and key      derivation can easily add channel binding as proposed in this      draft.  On the other hand, including identities into key      derivations requires the modification of EAP methods.  For      instance, many EAP methods specify how MSK and other keying      material is derived and adding channel binding by adding      identifiers would need to be specified for each method      individually. [BA] I think you are making assumptions about how the keys are mixed inthat may not necessarily be valid.  For example, couldn't the mixingoccur in a lower layer rather than in the EAP method?  A more validreason would be that EAP methods need to be lower layer independent,whereas Channel Bindings often are not -- so that mixing them intoEAP keying material could be an issue.  However, this argument wouldnot hold for mixing that occurs in a lower layer.  This practice isalready incorporated into lower layer specifications such as IEEE 802.11r.    o  Client and authentication server may communicate on different      layers with the authenticator and thus receive different      identifiers that may belong to the same device.  A server may be      able to recognize which different identifiers belong to the same      device (e.g. by performing a table look up).  This scenario cannot      be solved by hashing identities into keys. [BA] I think what you're trying to say here is that the set of channelbindings may vary between authenticator implementations, no? 4.  Trust Model [BA] I think that you need to include this introduction earlier in thedocument.     Channel bindings are always provided between two communication   endpoints, i.e. here between client and server, who communicate   through an authenticator in pass-trough mode (as illustrated in   Figure 1).  Channel binding prevents attacks by rogue authenticators   in pass-trough mode (see Example Attacks).  Clancy & Hoeper          Expires August 21, 2008                [Page 4]Internet-Draft                 EAP-CHBIND                  February 2008                         ---------------------------------------------     --------   info1   |   -------------     info2     -----------   |    |EAP peer| <--------|  |Authenticator| ----------> |Auth.Server|  |     --------           |   -------------               -----------   |       |                |                                     |       |       |                |                 Home Domain         |       |       |                 ---------------------------------------------       |                                                      |       |                                                      |       |                     Channel binding                  |       |<---------------------------------------------------->|                   Figure 1: Overview of Channel Binding [BA] There is an important piece missing from this picture -- theneed of the first hop proxy to check the *correctness* of the informationpassed by the authenticator.  For example, only the first hop can checkif the NAS-Identifier attribute actually corresponds to the source IPaddress of the authenticator; downstream proxies or servers cannot checkthis, since the information will have been 'laundered' by the time itreaches them.     During an EAP execution, an authenticator presents information info1   and info2 to client and server, respectively.  Such information can   include the authenticator's identifier/address and/or advertised   network information (such as offered services and billing   information).  To prevent attacks by rogue authenticators, the server   must be able to recognize any inconsistencies in info1 and info2.   Therefore, the client sends info1 to the server and upon performing   an inconsistency check, the server notifies the client about the   result.  Only in case of a positive result, channel binding is   provided and the EAP session continues.  Note that under some   circumstances, the client could be able to check for inconsistencies;   however the check is generally easier to implement on the server.   The trust model for channel binding consists of three parties, namely   a client, an authentication server and an authenticator in pass-   through mode as illustrated in Figure 1.  In this trust model, client   and authentication server are honest while the authenticator is   maliciously sending false information to client and/or server.  The   three parties have the following trust relationships:   o  The server trusts that the channel binding information received      from the client is the information that the client received from      the authenticator (i.e. info1)   o  The client trusts the channel binding result received from the      server   o  The server trusts the identifier received from the authenticator [BA] The first hop cannot just trust the identifer received from the authenticator -- it is *required*  that it be able to verify it, based on configuration.    Note that the model includes all cases in which authenticator and   authentication server communicate over one or more intermediate nodes   as long as 1) these nodes only forward the messages (e.g. routers)   and 2) authenticator and server communicate using an end-to-end   protocol (e.g.  AAA).  However, roaming scenarios with proxies are   out of the scope of this document. [BA] Roaming scenarios are actually quite central to the problem statementbecause almost all the severe security vulnerabilities relate to roaming in some way.  ______________________

 EMAILING FOR THE GREATER GOOD

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

---

From: Charles Clancy <[email-masked]>
Date: Thu, 26 Jun 2008 08:33:35 -0400

Bernard,

00 was an extremely preliminary version.  01 has been completed for a 
while now, just not posted.  I just posted it.  We'll go through your 
comments and see which of them are addressed in the new version (I 
suspect many of them will be).

Regardless, thank you for your review.

--
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland

Bernard Aboba wrote:
> Overview
>  
> I have read this document and have found several major issues with it.  
> As a result,
> I don't think it is currently suitable for adoption of an EMU WG work item.
>  
> Issues:
>  
> a. Mistatement of the 'Lying NAS' problem. 
>  
> The 'Lying NAS' problem does not just concern the issue of whether the 
> authenticator
> gives different information to the peer and the server;  it also relates 
> to the
> ability of the server to verify that the information is actually correct.
>  
> The document does not refer to the necessity of first-hop verification 
> of the
> information provided by the authenticator, such as the mapping between the
> NAS-Identification attributes and the source address. 
>  
> The need for verification impacts the trust model in some major ways, since
> not only does the authentication server need to trust that the authenticator
> attributes have not been modified along the path -- it also needs to 
> trust that
> the first hop was configured to check the validity of attributes that 
> only it can
> check. 
>  
> For example, it's not much help for the AAA Server to verify that the RSN IE
> provided to the STA is the same one it got from the AP if there is no way of
> verifying whether the AP actually was configured to emit that RSN IE.
>  
> b. Lack of applicability to the roaming case.
>  
> The document states that Channel Bindings only apply to the non-roaming 
> case.
> I'm not sure why this restriction is mentioned because the issue of 
> verification
> is present even within a single domain. 
>  
> c. Discussion of 'fuzzy' comparisions.  By their nature, Channel 
> Bindings may include
> information that may be opaque to the AAA server, such as the RSN IE.  
> Given that
> the AAA server may not be capable of understanding the contents of the 
> attributes,
> I question whether the concept of 'fuzzy comparisons' makes sense.  
> Rather, I think
> we need to assume that a AAA server will probably only be capable of 
> 'byte by byte'
> comparisons in most cases.  This is an important issue, because it 
> affects the structure
> of data that needs to be provided by the client, and avoid potential 
> 'canonicalization'
> issues that could greatly complicate the successful implementation of 
> channel
> bindings.
>  
> d. Discussion of lower layer channel bindings.
>  
> The document does not discuss the potential use of channel bindings in 
> lower layers such
> as IEEE 802.11r.  I think that this is important since lower layers such 
> as 11r do bind EAP
> keying material to lower layer parameters (such as the peer and 
> authenticator MAC address).
> Thus, lower layer channel bindings is an alternative that should be 
> discussed.
>  
> e. Development of requirements.  If this document is going to include an 
> evaluation of
> alternative approaches, then it needs to clearly articulate the 
> requirements for such an
> evaluation.
>  
> f. Clear distinction between RFC 5056 and 3748 channel binding 
> concepts.  The current
> document is not as clear as it could be on this.  The RFC 5056 channel 
> binding concept
> is closer to that of 'cryptographic binding' than it is to EAP channel 
> bindings.  This should
> be made clear.
>  
> g. Exploration of operations implications.  There are a number of 
> barriers to successful
> implementation of channel bindings that need to be explored, including:
>  
> 1. Required configuration for first-hop AAA clients.
> 2. Potential changes to drivers and AAA servers.
> 3. Potential impacts on authentication reliability.
>  
> h. Motivation.  Why should we care about Channel Bindings?  Given the 
> operational costs
> I'd suggest that the document needs to make a case that there is a 
> potentially serious
> security vulnerability here.  Such a case probably involves some kind of 
> financial fraud
> issue which is most likely in a roaming situation - which is 
> unfortunately a scenario that the
> document rules out of scope.
>  
>  
> Some specific comments.
>  
> ============================
>  
> Abstract
>    This document defines how to implement channel bindings for
>    Extensible Authentication Protocol (EAP) methods.
>  
> [BA] I'd add a definition of the problem to the abstract goals.
>  
> 
> Section 1
>    A well-documented problem with the current Extensible Authentication
>    Protocol (EAP) architecture [RFC3748] when used in pass-through
>    authenticator mode is the so-called 'lying NAS' problem.  Here, a
>    Network Access Server (NAS), or pass-through authenticator, may
>    authenticate to the backend AAA infrastructure using one set of
>    credentials, while representing contrary information to EAP clients.
>  
> [BA] The 'lying NAS' problem is not really about credentials, since in
> RADIUS the identity of a RADIUS client is defined by its IP address.
> Rather, the issue is providing different *information* (e.g.
> Called-Station-Id, NAS-Identifier, etc.) to the peer and AAA server.
>  
>    A concrete example of this may be an IEEE 802.11 access point with a
>    security association to a particular AAA server.  While there may be
>    some identity tied to that security association, there's no reason
>    the access point need advertise the same identity to clients. 
>  
> [BA] The identity used in the AAA server security association and the
> one advertised to clients do not necessary have to agree, even if the
> NAS is not lying.
>  
>    In
>    fact, it may include whatever information in its beacons (to include
>    different SSID or security properties) it desires.  This could lead
>    to situations where, for example, a client joins one network that's
>    masquerading as another.
>  
> [BA] The SSID is a good example, but the 'security properties' (e.g. RSN IE)
> are not provided to the AAA server.  Therefore it is
> not possible for a NAS to 'lie' to the AAA server about the RSN IE it
> sent in a Beacon.
> 
>    Channel bindings [RFC5056] seek to enforce a stronger security
>    relationship between the three entities, by allowing the client and
>    server to compare their relative perception of the authenticator's
>    identity in a secure channel. 
> 
> [BA] RFC 5056 specifically states that it does not apply to EAP, and
> that the use of the term 'Channel Bindings' is not the same as the
> one used in EAP.  As a result, I'd recommend deleting the above
> paragraph or clarifying the relationship.
>  
>    This document defines how to use 'AAA
>    Payloads' [I-D.clancy-emu-aaapay] within EAP methods to implement
>    channel bindings.  Unlike [RFC5056], channel binding in EAP context
>    does not ensure binding different layers of a session but rather the
>    information advertized to client and authentication server by an
>    authenticator acting as pass-through device during an EAP session.
>  
> [BA] You might say that 'Channel Bindings' in RFC 5056 corresponds to
> the term 'cryptographic binding' in EAP.
>  
>    It is preferable to use this idea, rather than hashing identity
>    information directly into keys, for a number of reasons:
>    o  It allows for fuzzy comparisons of entity names, rather than
>       requiring absolute.  This can facilitate deployment and debugging.
>  
> [BA] Not sure this is convincing because it's doubtful whether
> 'fuzzy comparisons' are implementable in the alternative approach either.
> Wouldn't this require the AAA server to be able to parse the attributes
> and 'understand' them in some deep manner? 
> 
>    o  Any EAP method that provides mutual authentication and key
>       derivation can easily add channel binding as proposed in this
>       draft.  On the other hand, including identities into key
>       derivations requires the modification of EAP methods.  For
>       instance, many EAP methods specify how MSK and other keying
>       material is derived and adding channel binding by adding
>       identifiers would need to be specified for each method
>       individually.
>  
> [BA] I think you are making assumptions about how the keys are mixed in
> that may not necessarily be valid.  For example, couldn't the mixing
> occur in a lower layer rather than in the EAP method?  A more valid
> reason would be that EAP methods need to be lower layer independent,
> whereas Channel Bindings often are not -- so that mixing them into
> EAP keying material could be an issue.  However, this argument would
> not hold for mixing that occurs in a lower layer.  This practice is
> already incorporated into lower layer specifications such as IEEE 802.11r.
> 
>    o  Client and authentication server may communicate on different
>       layers with the authenticator and thus receive different
>       identifiers that may belong to the same device.  A server may be
>       able to recognize which different identifiers belong to the same
>       device (e.g. by performing a table look up).  This scenario cannot
>       be solved by hashing identities into keys.
>  
> [BA] I think what you're trying to say here is that the set of channel
> bindings may vary between authenticator implementations, no?
> 
> 4.  Trust Model
>  
> [BA] I think that you need to include this introduction earlier in the
> document.
>  
>    Channel bindings are always provided between two communication
>    endpoints, i.e. here between client and server, who communicate
>    through an authenticator in pass-trough mode (as illustrated in
>    Figure 1).  Channel binding prevents attacks by rogue authenticators
>    in pass-trough mode (see Example Attacks).
>  
>  
> 
> Clancy & Hoeper          Expires August 21, 2008                [Page 4]
> 
> Internet-Draft                 EAP-CHBIND                  February 2008
> 
>                          ---------------------------------------------
>      --------   info1   |   -------------     info2     -----------   |
>     |EAP peer| <--------|  |Authenticator| ----------> |Auth.Server|  |
>      --------           |   -------------               -----------   |
>        |                |                                     |       |
>        |                |                 Home Domain         |       |
>        |                 ---------------------------------------------
>        |                                                      |
>        |                                                      |
>        |                     Channel binding                  |
>        |<---------------------------------------------------->|
>                    Figure 1: Overview of Channel Binding
>  
> [BA] There is an important piece missing from this picture -- the
> need of the first hop proxy to check the *correctness* of the information
> passed by the authenticator.  For example, only the first hop can check
> if the NAS-Identifier attribute actually corresponds to the source IP
> address of the authenticator; downstream proxies or servers cannot check
> this, since the information will have been 'laundered' by the time it
> reaches them.
>  
>    During an EAP execution, an authenticator presents information info1
>    and info2 to client and server, respectively.  Such information can
>    include the authenticator's identifier/address and/or advertised
>    network information (such as offered services and billing
>    information).  To prevent attacks by rogue authenticators, the server
>    must be able to recognize any inconsistencies in info1 and info2.
>    Therefore, the client sends info1 to the server and upon performing
>    an inconsistency check, the server notifies the client about the
>    result.  Only in case of a positive result, channel binding is
>    provided and the EAP session continues.  Note that under some
>    circumstances, the client could be able to check for inconsistencies;
>    however the check is generally easier to implement on the server.
>    The trust model for channel binding consists of three parties, namely
>    a client, an authentication server and an authenticator in pass-
>    through mode as illustrated in Figure 1.  In this trust model, client
>    and authentication server are honest while the authenticator is
>    maliciously sending false information to client and/or server.  The
>    three parties have the following trust relationships:
>    o  The server trusts that the channel binding information received
>       from the client is the information that the client received from
>       the authenticator (i.e. info1)
>    o  The client trusts the channel binding result received from the
>       server
>    o  The server trusts the identifier received from the authenticator
>  
> [BA] The first hop cannot just trust the identifer received from the
> authenticator -- it is *required*  that it be able to verify it, based 
> on configuration.
>  
>    Note that the model includes all cases in which authenticator and
>    authentication server communicate over one or more intermediate nodes
>    as long as 1) these nodes only forward the messages (e.g. routers)
>    and 2) authenticator and server communicate using an end-to-end
>    protocol (e.g.  AAA).  However, roaming scenarios with proxies are
>    out of the scope of this document.
>  
> [BA] Roaming scenarios are actually quite central to the problem statement
> because almost all the severe security vulnerabilities relate to roaming in
> some way. 
> ______________________
> 
> i <http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood> 
> ------------------------------------------------------------------------
>