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

[Hannes Tschofenig <[e-mail]>]

Hi Sam, 

thanks also for the quick response to this mail. 

On Aug 16, 2012, at 3:35 PM, Sam Hartman wrote:

>>>>>> "Hannes" == Hannes Tschofenig <[e-mail]> 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.
> 

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. 

> 
> 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.


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

>    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.
> 
Great to hear. 

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

>    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.
> 
Hmmm. Maybe I should re-read GSS-EAP. Will do that and then I will come back to this issue. 

Ciao
Hannes

> 
>    Hannes>  Ciao Hannes
> 
>    Hannes> _______________________________________________ abfab
>    Hannes> mailing list [e-mail]
>    Hannes> https://www.ietf.org/mailman/listinfo/abfab
>