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