> -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:[email protected]] > Sent: Tuesday, August 21, 2012 9:18 PM > To: [email protected] > Cc: Jim Schaad > Subject: Re: [abfab] Comments on draft-ietf-abfab-eapapplicability-00.txt > > 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." >
Looks fine > > > 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. " > Looks good and I think matches what is in the architecture doc. > > > 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." > Yes I think that is much better > > 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. Unhappy but I can live with it. > > > 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. > Ok > > 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. " OK - I still worry about the possibility that the service will attempt to change its own name (parameters) based on the parameters passed from the peer to the authenticator, but this is probably an issue in my own head and may not be a real one. Jim _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
