[abfab] draft-ietf-abfab-arch-03.txt - GSS

[Hannes Tschofenig <[e-mail]>]

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