EAP Channel Bindings Charles Clancy Katrin Hoeper IETF 76 Hiroshima, Japan November 08-13, 2009

Document (Recent) History, March `09 – consensus that draft is ready for WGLC at IETF 74, May `09 – tried to address comments from Klaas detailed review, July `09 – added clarifying text to address more comments on list – more discussions about “authorization” capabilities of channel bindings and EAP in general, October `09 – narrowed scope to solving lying NAS/ lying provider problems, i.e. removed authorization capabilities – updated AAA attributes for channel binding TLVs

Change #1: “scope of draft” What aspect of channel bindings should and can be solved by the proposed protocol? – mitigate lying NAS problem – mitigate lying provider problem Removed: – check whether peer is authorized to access requested services in manner described by NAS Section 1

Change #1: “scope of draft” (cont’d) Solution: specify channel binding protocol – protocol includes verification of channel binding information Removed: policy data base i1 Local DB info CB_success/failure(i1, i2, info) i2 AAAEAP peer EAP server Authenticator

Why we still need a local database AAA protocol not sufficient for comparing i1 and i2 – i1 and i2 may be both false – i2 likely not sufficient to detect lying providers due to “message laundering” by AAA intermediaries – i1 is not restricted to AAA attributes not all information of interest can be encoded in AAA attributes and defining numerous new AAA attributes seems like a bad idea! Using a local DB enables to check – against a trustworthy set of information – consistency of i1 and i2 rather than equality, e.g. do MAC and IP address belong to the same device ⇒ authentication & integrity of channel binding info (not authorization!)

Change #2: “what is verified”? Channel binding information – i1: any info part of the NAS beacon/EAP Identity request – i2: any AAA attribute exchanged between authenticator and AAA server as part of on-going EAP exchange Channel binding verifications, check whether 1.the authenticator is lying to the peer (i1 false?) 2.the authenticator (or AAA intermediaries) is lying to the AAA server (i2 false?) Removed: – rules derived from network policies & stored in local DB – check whether authenticator is violating any policies Section 5.2

Change #3: “set up local database” Simplified set up of local data base – only needs to contain known information about authenticators and roaming partners e.g. MAC/IP addresses, roaming fees used for consistency check of i1 and i2 Removed: – policy engines – training phase to learn behavior that should be authorized – policy rules for home and service provider networks Section 10

Change #4: “attribute update” Removed outdated s attribute from list of channel binding TLVs Section 7.3

Conclusions All open issues on the list have been addressed in the -04 draft Request WG review of -04 version Ready for WG last call?