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

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 16 Aug 2012 10:08:41 +0300

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 16 Aug 2012 08:35:07 -0400

>>>>> "Hannes" == Hannes Tschofenig <[email-masked]> writes:

    Hannes> Section 3.2:

    Hannes>    However there are a variety of situations where this
    Hannes> authentication is not checked for policy or usability
    Hannes> reasons.
   
    Hannes> We cannot make the assumption that the software does not do
    Hannes> authentication or check the result of the authentication
    Hannes> process since then the entire security solution does not
    Hannes> work anymore. 

Section 3.2 is all about providing alternatives when this check is not
done.
This check is not done in practice a *lot*. There are lots of
application libraries that do not check server certificates.

Actually the TLS channel bindings have been designed with a couple of
strategies for dealing with load balancers and in general for allowing a
server to securly indicate that it cannot provide channel bindings
and so server certs are all you get.
    Hannes> consistent with the GSS-API specification.  XXXThere is an
    Hannes> open question here as to the details; today RFC 5554
    Hannes> governs.  We could use that and the current draft assumes we
    Hannes> will.  However in Beijing we became aware of some changes to
    Hannes> these details that would make life much better for GSS
    Hannes> authentication of HTTP.  We should resolve this with kitten
    Hannes> and replace this note with a reference to the spec we're
    Hannes> actually following.

    Hannes> Regarding the inline note have we come to a conclusion about
    Hannes> this issue already?

Yeah, we're just using the existing stuff.
Nothing new has materialized in the IETF.

    Hannes> Section 3.3:

    Hannes>    GSS-API provides a pseudo-random function.  While the
    Hannes> pseudo-random function does not involve sending data over
    Hannes> the wire, it provides an algorithm that both the initiator
    Hannes> and acceptor can run in order to arrive at the same key
    Hannes> value.  This is useful for designs where a successful
    Hannes> authentication is used to key some other function.  This is
    Hannes> similar in concept to the TLS extractor.  No current IETF
    Hannes> protocols require this.  However GSS-EAP supports this
    Hannes> service because it is valuable for the future and easy to do
    Hannes> given per- message services.  Non-IETF protocols are
    Hannes> expected to take advantage of this in the near future.

    Hannes> I would delete this paragraph since it is confusing, is not
    Hannes> relevant for the work we are doing, and does not relate to
    Hannes> the previous paragraph either.

How is this not relevant?
GSS-EAP implementations are required to provide gss_pseudo_random.

    Hannes>  Ciao Hannes

    Hannes> _______________________________________________ abfab
    Hannes> mailing list [email-masked]
    Hannes> https://www.ietf.org/mailman/listinfo/abfab

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 17 Aug 2012 14:55:49 +0300

Hi Sam, 

thanks also for the quick response to this mail. 

> application libraries that do not check server certificates.

I guess we just have a different understanding here. 

My strategy is to fix the lack of certificate checking. 

Your strategy is to define a new specification that provides an additional mechanism for doing a similar check assuming that it would get implemented. 

I am failing to see why people would implement your alternative mechanisms when they did not bother to implement the certificate checking. 

> and so server certs are all you get.

Interesting. I didn't know that. 
Where do I read more about this? 

> Nothing new has materialized in the IETF.
Great to hear. 

Maybe it would be good to fix this note in the text so that we can finish it asap.  

> GSS-EAP implementations are required to provide gss_pseudo_random.
Hmmm. Maybe I should re-read GSS-EAP. Will do that and then I will come back to this issue. 

Ciao
Hannes