Re: [Emu] Working Group Last Call for draft-ietf-emu-chbind-04.txt (part 2)

["Hoeper Katrin-QWKN37" <[e-mail]>]

Bernard, All

 

See my comments inline.

 

________________________________

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Bernard Aboba
Sent: Tuesday, December 08, 2009 12:12 AM
To: [e-mail]
Subject: Re: [Emu] Working Group Last Call for
draft-ietf-emu-chbind-04.txt (part 2)

 

Section 5.1

   The local database is perhaps the most important part of this system.

   In order for the EAP server or AAA server to know whether i1 and i2

   are correct, they need access to trustworthy information, since an

   authenticator could include false information in both i1 and i2.

   Additional reasons why such a database is necessary for channel

   bindings to work are discussed in the next subsection.  The

   information contained within the database could involve wildcards.

   For example, this could be used to check whether WiFi access points

   on a particular IP subnet all use a specific SSID.  The exact IP

   address is immaterial, provided it is on the correct subnet.



[BA] Is it really true that the IP address of the NAS is always
immaterial?  For example, couldn't a 

NAS lie about its IP address in order to impersonate another NAS? 
[KH] No, this is an example for the use of wildcards, i.e. it doesn't
mean IP addresses of the NAS are always immaterial.




   During an EAP method execution with channel bindings, the goal is to

   transport i1 from the peer to the EAP server, and allow the system to

   verify the consistency of i1 provided by the peer, i2 provided by the

   authenticator, and the information in the local database.  Upon the

   check, the EAP server sends a message to the peer indicating whether

   the channel binding validation check succeeded or failed and

   optionally includes all or some of the information that was used in

   the check.  The message flow is illustrated in Figure 1.



[BA] Is it always necessary for the EAP server to provide information to
the peer 

about why the channel binding check succeeded or failed?  While this
info might be helpful for

debugging, it seems like there could be situations in which the AAA
server just returns an

Accept/Reject indication. 
[KH] No, it is not necessary; this is why the text reads "and optionally
includes all or some of the information that was used in the check."




   If the compliance of i1 or i2 information with the authoritative

   policy source is mandatory and a consistency check failed, then after

   sending a protected indication of failed consistency, the EAP server

   MUST send an EAP-Failure message to terminate the session.  If the

   EAP server is otherwise configured, it MUST allow the EAP session to

   complete normally, and leave the decision about network access up to

   the peer's policy.



[BA] I would suggest that normative language is not appropriate here.
For one thing, an EAP-Failure

does not actually result in the host being denied access to the network
-- an Access-Reject is what

accomplishes this.  Also, since an EAP-Failure (or EAP-Success) may not
be delivered, it doesn't make

sense to rely on it.  Furthermore, couldn't there be situations where
rather than denying access 

some other action is taken, such as putting up a warning message,
isolating the host in some way

(e.g. filters or VLAN setting, etc.)?  
[KH] OK. I guess simply mentioning that in some cases a failed channel
binding leads to an EAP-Failure message is sufficient. Text will be
revised accordingly.



Section 5.2



   These checks enable the EAP server to detect lying NAS/authenticator

   in enterprise networks and lying providers in service provider



[BA] As noted in the previous message, these checks do not actually
enable the determination of whether

a provider is lying. 
[KH] Agree, statement should be put in perspective.




   Checking the consistency of i1 and i2 is nontrivial, as has been

   pointed out already in [HC07].  First, i1 can contain any type of

   information propagated by the authenticator, whereas i2 is restricted

   to information that can be carried in AAA attributes.  



[BA] Actually, i1 can only contain information that is both propagated
by the authenticator *and*

passed up by the host in the proper format.  This requires coordination
between the

driver implemented on the host and the EAP method.   In practice, this
has been a major impediment

to implementation of Channel Bindings, because without driver changes,
many of the parameters desired

by channel binding implementations will not be available. 
[KH] Will add the second condition to the sentence. The required driver
updates are considered in Section 10.




Similarly, the database referred to in this section also requires a
non-trivial effort to put together,

comparable to the "wire map" required to support geographic location or
emergency services calling. 



   For example, if the EAP MTU is 1020 octets, and EAP-GPSK is used as

   the authentication method, and maximal-length identities are used, a

   maximum of 384 octets are available for conveying channel binding.



[BA] This is an important point -- and one that indicates that the
ability to implement channel

bindings is limited on EAP methods that don't support fragmentation.  




[KH] Indicating this was the point of this paragraph. Will add another
sentence to further clarify.


Section 6.3



   If transporting data within a lower-layer's secure association

   protocol (SAP), this protocol MUST support transport of integrity

   protected data using a key known only by the EAP peer and EAP server,

   and not known to the authenticator.  There must be mechanism whereby

   the authenticator can transport the protected payloads to the EAP

   server, either via a AAA protocol or some other means, and receive a

   protected result.



[BA] This paragraph does not make sense, because by definition the SAP

exchange occurs between the authenticator and the peer, and therefore

any keys derived in the process need to be known by the authenticator

and the peer.  In a number of cases (such as IKEv2), the EAP server

only doesn't know the key used by the SAP, but it is an explicit

design requirement that this not be possible.  
[KH] Needs to be clarified. It was meant that the data is transported
between peer and the authenticator via SAP but that the data is
protected by a key not known to the authenticator.




   This protocol MUST support exporting channel binding data to the AAA

   subsystem on the EAP server for validation.  The SAP must have access

   to channel binding data required for transport to the EAP server.



[BA] The last sentence also doesn't make sense.  Elsewhere in the
document

it says that the authenticator is not supposed to have access to the

channel bindings data, but here it implies that it must have access,

since the SAP is run between the peer and authenticator. 
[KH] Good catch. The authenticator should not have access to the
unprotected data, it just needs to be able to transport the information
to the EAP server. Needs to be revised.




Section 7.1



7.1.  Requirements for Lower-Layer Bindings



   Lower-layer protocols MUST support EAP in order to support EAP

   channel bindings.  These lower layers MUST support EAP methods that

   derive keying material, as otherwise no integrity-protected channel

   would be available to execute the channel bindings protocol.  Lower-

   layer protocols need not support traffic encryption, since this is

   independent of the authentication phase.



[BA] Channel Bindings can still be used even on lower layers that don't
use keying material.  For

example, an EAP method supporting channel bindings could be used with a
wired network supporting

IEEE 802.1X-2004. Since the EAP server/AAA server will still obtain
i1/i2 in this situation, why

should it matter whether an integrity-protected channel is in place?  
[KH] Because nobody including  the authenticator should  be able to
alter i1/i2.








 

 

<http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood>