>>>>> "Hannes" == Hannes Tschofenig <[email protected]> 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 protected]
Hannes> https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
