Subject: Re: [abfab] Comments on draft-ietf-abfab-eapapplicability-00.txt

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 22 Aug 2012 04:18:03 +0000

Hi Jim,

Thanks for the review, 

Somehow I lost the original message so I've reproduced it from the archives below:

> Abstract.
> 1. Expand the EAP and ABFAB
> 2.  Do you really want to talk about the use cases in the sentence?
> 

How about:

"This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC3748
 to reflect recent usage of the EAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) working group."

>  Uses of EAP for Application-Layer Access
> 1.  It is not clear to me that using channel bindings informs the peer what
> services are provided by an authenticator.  What I think is given is that
> the peer can validate that A specific service is provided.
> 

[Joe]  There is something wrong with the text,  this should be better:

"Without channel bindings, a peer cannot verify if an authenticator is authorized to provide an advertised service. "

> 2. para #2 says that which service is needed, but the previous paragraph is
> talking about different services not different qualities of a specific
> service.  I don't think this follows well.
> 
> 3.  Swapping sentences 2 and 3 in para #2 might be reasonable - this
> describing that the quality of service can be important and then giving an
> example of why that is true.
> 

[Joe] 

> 4.  Do we have the ability to discuss the security implications in channel
> binding?  In order for this to be true you need to have the ability to have
> a distinct name of the service between the low and high value versions of
> the same service.  This would mean multiple names for the "print" service.
> It is not clear that this is how people are going to do this.
> 

[Joe]   You have to have some way of differentiating the types of services.   This could be by name or it could be by some other parameter.  for example you can have a print service with a confidential attribute which may be true or false.  There are many other approaches as well.  I'm not sure that this is the document that should detail this.  

> 5.  After reading this for a while, I think that part of my problem is that
> I am picking up a different meaning for the word service.  I think of
> service as a print service, not of as "The high security print service
> running on machine foo.example.com".  If this is the case then that might be
> the clarification that removes the above comments.
> 

[Joe]  OK, so would the following help:

"However as additional services use EAP for authentication, the
   distinction of which service is being contacted becomes more
   important.   Application services might have different properties. 
   Consider an environment with multiple printers some of which provide a confidential service to output documents to a controlled location. If a peer
   sent a document to the wrong service then potentially sensitive
   information might be printed in an uncontrolled location and be disclosed.  In addition, it
   might be more likely that a low-value service is compromised than
   some high value service.  If the high-value service could be
   impersonated by a low-value service then the security of the overall
   system would be limited by the security of the lower value service."

> 6. I think that you might talk about the cases where channel binding COULD
> be required even for network authentication.  The fact that it is not
> required does not mean that it cannot be used.  One issue is going to be how
> an IdP identifies a network authentication service from a different service
> for the purposes of deciding if channel binding is going to be required.
> 

[Joe] I agree with the discussion on the list that says this is out of scope for this document. 

> 7.  Is it just important to prove that the EAP MSK is mutually held, or is
> it REQUIRED?  What are the implications of not doing so?
> 

[Joe] REQUIRED,

"It is REQUIRED for the application layer to prove possession of the
  EAP MSK between the EAP Peer and EAP Authenticator.  Failing to validate the possession of the EAP MSK can allow an attacker to insert himself into the conversation and impersonate the peer or authenticator.  

> Security Considerations
> 1. When doing channel binding, it is highly desirable (required?) that the
> authenticator is not able to modify (and potentially to see?) the channel
> binding data passed from the peer to the authenticator (or reverse) as part
> of the authentication process.

[Joe]  I don't think confidentiality is required. How about:

"When doing channel binding it is REQUIRED that the authenticator is not able to modify the channel binding data passed between the peer to the authenticator as part of the authentication process.  "