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

[Sam Hartman <[e-mail]>]

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


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 [e-mail]
    Hannes> https://www.ietf.org/mailman/listinfo/abfab