Hi Jim, Hi all, I now managed to read through the GSS-API part of the draft as well. A few minor remarks.
Section 3.1: The authentication section is indeed interesting and I understand that there is a challenge to describe it properly. However, may the way how the story was phrased for earlier EAP-related publications may help. I believe that the situation is similar to the Secure Association Protocol, as http://tools.ietf.org/html/rfc4962 calls it. Here is the short description: A protocol for managing security associations derived from EAP and/or AAA exchanges. The protocol establishes a security association, which includes symmetric keys and a context for the use of the keys. An example of a Secure Association Protocol is the 4-way handshake defined within [802.11i]. The properties of the exchange between the GSS initiator and the GSS acceptor can similar to the IEEE 802.11i 4-way handshake protocol, i.e., where the Supplient and the Access Point do not authenticate each other directly but they both independently derive keying material obtained via the EAP MSK to confirm through this protocol exchange that they indeed know the same keying material. A possible variation (which is also supported with the ABFAB work) is that there is indeed direct authentication of the acceptor to the initiator (when TLS with server-side authentication is used in GSS). Here the appropriate comparison would be the IKEv2-EAP integration. The details matter here and since I am not the GSS-API expert I am wondering how the exchange looks in detail. Maybe a diagram would help to illustrate how the keying material is derived. Section 3.2: However there are a variety of situations where this authentication is not checked for policy or usability reasons. We cannot make the assumption that the software does not do authentication or check the result of the authentication process since then the entire security solution does not work anymore. If this check is not done how can we assume that other checks are done instead. Even when it is checked, if the trust infrastructure behind the TLS authentication is different from the trust infrastructure behind the GSS-API mutual authentication then confirming the end-points using both trust infrastructures is likely to enhance security. If the endpoints of the GSS-API authentication are different than the endpoints of the lower layer, this is a strong indication of a problem such as a man-in-the-middle attack. Channel binding provides a facility to determine whether these endpoints are the same. I believe the cases that you will detect using this technique are TLS load balancers that terminate the TLS at the edge of the network. Are those the main concern or are you also trying to prevent "TLS inspection" in the style of http://www.juniper.net/techpubs/en_US/idp5.0/topics/concept/intrusion-detection-prevention-ssl-decryption-overview.html The GSS-EAP mechanism needs to support channel binding. When an application provides channel binding data, the mechanism needs to confirm this is the same on both sides consistent with the GSS-API specification. XXXThere is an open question here as to the details; today RFC 5554 governs. We could use that and the current draft assumes we will. However in Beijing we became aware of some changes to these details that would make life much better for GSS authentication of HTTP. We should resolve this with kitten and replace this note with a reference to the spec we're actually following. Regarding the inline note have we come to a conclusion about this issue already? RFC 5056 channel binding (also called GSS-API channel binding when GSS-API is involved) is not the same thing as EAP channel binding. EAP channel binding is also used in the ABFAB context in order to implement acceptor naming and mutual authentication. Details are discussed in the mechanisms specification [I-D.ietf-abfab-gss-eap]. I would put this sentence at the beginning of Section 3.2 with a "Note: ...". Section 3.3: s/A number of GSS-API mechanisms suchs as Kerberos [RFC1964] split the problem into two parts./A number of GSS-API mechanisms, such as Kerberos [RFC1964], split the name into two parts. Actually, I do not follow the line of argument in Section 3.3. What is the problem you are solving? I understand that the user either enters a URI of the resource (or gets it from somewhere else). The URI indicates the resolution mechanism. In our cases it will typically involve a DNS-based resolution mechanism for resolving the hostname part to an address (potentially through a series of resolution steps). Section 3.4: As with mutual authentication, per-message services will limit the set of EAP methods that are available. Any method that produces a Master Session Key (MSK) should be able to support per-message security services. I wouldn't say that it restricts the choice of EAP methods in any realistic way since EAP methods have to generate keying material also for other reasons and all EAP methods published since about 15 years expert the MSK. EAP-MD5 is one method that would work but we have already standardized a Standards Track replacement for it. I would also suggest to rephrase the last sentence to: " Any EAP method that produces a Master Session Key (MSK) is able to support per-message security services using the procedure described in [X]. " In [X] we put the reference to the document that explains how the MSK that is make available to the relying party is further derived to create these session keys for per-message security protection, which is http://www.ietf.org/id/draft-ietf-abfab-gss-eap-09.txt I believe. GSS-API provides a pseudo-random function. While the pseudo-random function does not involve sending data over the wire, it provides an algorithm that both the initiator and acceptor can run in order to arrive at the same key value. This is useful for designs where a successful authentication is used to key some other function. This is similar in concept to the TLS extractor. No current IETF protocols require this. However GSS-EAP supports this service because it is valuable for the future and easy to do given per- message services. Non-IETF protocols are expected to take advantage of this in the near future. I would delete this paragraph since it is confusing, is not relevant for the work we are doing, and does not relate to the previous paragraph either. Ciao Hannes _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
