Re: [David Leonard] draft-ietf-secsh-gsskeyex-09.txt comments

[Sam Hartman <hartmans-ietf%mit.edu@localhost>]

>>>>> "Bill" == Bill Sommerfeld <sommerfeld%sun.com@localhost> writes:

    Bill> On Fri, 2005-08-19 at 00:32, Jeffrey Hutzelman wrote:
    >> I have been asked to submit an updated version of this document
    >> within the next few days, in order to get it on the agenda for
    >> the September 1 IESG telechat.  Unless Bill finds that we have
    >> consensus for a change in this area, I will submit the draft
    >> early next week with no further changes.

    Bill> <wg chair hat on>

    Bill> I've reviewed the messages exchanged so far on this issue.

    Bill> I see what looks like consensus that there's a hole in the
    Bill> spec: the spec as it stands is silent on what an
    Bill> implementation should do if a hostname is not available.

    Bill> <wg chair hat off for remainder of message>
<ad hat on>

I agree that the spec is silent on what an implementation should do if
the hostname is not available.  It is not a requirement that the
specification define semantics for all cases only that sufficient
semantics be defined that all implementations are interoperable.  It
seems that is true for this specification in the case where a hostname
is available.  The fact that there are security concerns if the wrong
thing is done may make fixing this hole in the spec a requirement.
Never the less if we can come to quick consensus on a fix then we
should include it.

    Bill> IMHO, the main thing that matters for interoperability is
    Bill> the complete client system behavior rather than the behavior
    Bill> of the part of the system which is above the GSS *API*
    Bill> boundary.

    Bill> Given that this question is being looked at within GSSAPI,
    Bill> perhaps the best we can say for now is that if a client
    Bill> system implementing this specification is unable to securely
    Bill> determine which hostname and/or GSS target name to use, then
    Bill> it SHOULD NOT use this mechanism.


Jeff, would you please draft text to be added in an rfc editor note to
do this?

I'm seeking comments on the following three issues:

* Is Bill's solution a good idea
*  Is it a requirement that we fix this hole
* Is Jeff's text good?

My presumption (what I'll do absent comments) is as follows.  Bill's
solution is good and Jeff's text is good provided I don't find major
problems with it.  My presumption is also that fixing this issue is
optional.

<ad hat off>

My personal opinions do align with my presumptions.  I am still a bit
concerned that because of the security problems we may actually need
to fix this spec deficiency and so I'd much rather have agreement on a
fix than have to think about whether to block publication.