Sorry for going quiet for a week...  Comments in-line..

On 9/30/2010 10:05 PM, Joe Salowey wrote:
> On Sep 30, 2010, at 8:27 PM, Chris Hessing wrote:
>
>> Hi all,
>>
>> I sat down last night to implement channel bindings in XSupplicant, and had some questions about the functionality and intent of some pieces.   It is unclear to me if this discussion belongs here, or on the EMU list, so I figured I would start here.
>>
>> In Figure 1 of draft-ietf-emu-chbind-05, it seems that the exchange results in the communications ending in the wrong direction.    I am used to seeing the final EAP packet prior to the authentication server sending an Access-Accept headed from the EAP peer to the authentication server.  However, figure 1 and the included text indicate that once the EAP peer sends the i1 information to the authentication server, the server responds with a success or failure.
>>
>> At this point, it seems that the EAP peer needs to respond to the authentication server in order to complete the lock-step round trip.   I was unable to locate anything in the document that defines what this response should be.
>>
> [Joe] Figure 1 is the channel binding exchange taken out of context of the encapsulating method.  You are correct that if the peer receives an EAP message it must respond (unless it is EAP Success or EAP Failure).  The respons would depend upon the encapsulating method.  It could possible be piggy-backed upon another message in the method or it may just be an acknowledgement.   It might also be tempting to overload EAP-Success with CB success, however since EAP success is unprotected and unreliable it might not be the best thing.
>
> What encapsulating method are you using?  I haven't been able to follow Moonshot too closely so I'm pretty clueless here.
>

For my initial implementation, I am using TTLS.  However, I will be 
implementing support in FAST as soon as I understand the intent.

If I understand what you are saying, the idea is that following the CB 
success/failure that TTLS should just send a TLS-ACK?   Or did I 
misunderstand the intention?

>> The other thing that I ran across is also in the CB_success/failure message.  The text and diagram indicate that in the CB_success/failure message the authentication server can optionally send i1, i2, or other information used in the validation check.    What is unclear is how the "other information" should be encoded.   I would assume that the intent is that it would be encoded as an AVP, however the document also states that there may be information in use that isn't easily encoded in an AVP.   I suspect this is where the section "optionally includes all or some of the information that was used in the check" comes in.  However, if not all of the information is provided back to the EAP peer, then the peer won't be able to determine the exact reason for the failure.  It may even be possible that if the EAP peer evaluates the information provided from the authentication server it would discover that it should have passed, since the thing that caused the failure may not be included.   If the EAP peer can't use the information to give the user at the keyboard some idea of why things failed, then does it really make sense to have it in there?
> [Joe]  The details of the protocol not be specified by EMU yet.   In general, the direction is that there should be an encapsulating Data structure (such as a TLV) that can carry a number of Diameter AVPs.   Some folks like (or perhaps just me) that there might be other data you want to carry that you don't want to create a Diameter AVP for, but this really hasn't been proven so it seems that Diameter AVPs would be sufficient  (perhaps you have discovered a counter-example).  In general if the server is doing the evaluation I would expect it to include the i1 values it expected so the client can at least log the discrepancy if there is one.  Perhaps the next time the client could include information that was required that was missing.  Its not clear to me what "other information" would be and its not clear to me that the client really should deal with anything relating to i2 (unless its performing the validation instead of the server).   Do you have a concrete example of what you are sending for channel bindings?

I don't good example of sending data that wouldn't fit in an AVP.    
But, I suspect the reason that is in there is to cover that use case 
that nobody has come up with yet.

As far as the EAP peer using i2, the only purpose I can see with sending 
i2 to the peer is to allow the peer to understand what about the link 
caused the failure.   I like this idea because it deals with what I 
consider to be one of the major shortcomings of 802.1X.  It allows the 
supplicant to inform the user why they weren't able to get on the 
network, instead of just saying "you failed".

As for what I am sending in my implementation, I am using the 
NAS-Port-Type, and the Called-Station-Id as they appeared to be the only 
two in the document that applied.