[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GS2 update
Hi all! I have written a presentation that gives a status update:
I didn't realize until now that the meeting takes place 3-5AM my time
zone, and I'm leaving for another conference early tomorrow, so I
won't be able to participate even remotely.
There are basically three remaining issues for GS2 -- see the
presentation. I'd like to see GS2 move forward as fast as possible,
and my recommendation for each of the open issues are as follows:
Non-integrity capable mechanisms/credentials: This is a feature
request that came up during WGLC. I suggest to move forward with GS2
as-is today, decide later whether to revise GS2 or specify a "GS0"
(see presentation) to handle these mechanisms/credentials, if the need
Channel bindings: Have a normative reference on
draft-altman-tls-channel-bindings in GS2 and explain which TLS
finished message to use. Specific suggested solution is to replace:
For more discussions of channel bindings, and the syntax of the
channel binding data for various security protocols, see .
For more discussions of channel bindings, see . For the syntax
of channel bindings for TLS, see
[draft-altman-tls-channel-bindings]; GS2 uses the concatenation of
the initial client and the initial server "finished" TLS messages
as the channel binding.
Kerberos V5 GS2 mechanism name example: Move forward with GS2 as-is
today, and add the Kerberos V5 example mech name during AUTH48. The
example is non-normative, although I know implementers will use the
name verbatim so we should make an effort to make it correct.
I believe we can have GS2 ready for IETF-wide last call by next week
if adopt this approach.
Please, consider the delays that are created by alternative solutions,
and don't forget to attach specific text changes against GS2 -03 too.
Simon Josefsson <jas@xxxxxxxxxxx> writes:
> I have submitted an updated version of GS2. Until it shows up in the
> repository, you can view it from:
> I believe it closes all open issues, except for two that I have
> requested help on before:
> 1) Compute Kerberos V5 mech name.
> 2) Support for non-integrity capable GSS mechanisms.
> However, there has been many changes, and I may have missed some
> suggestions. Please consider the latest version ready to go except
> for the two issues above.
> The first issue above should be easy to close fast if someone can
> independently compute the GS2 mech name for Kerberos V5 OIDs. I'm
> worried about the lack of response on this matter, it would be a
> simple thing to resolve for anyone with interest in GS2. Does it
> indicate that nobody is interested in and/or committed to GS2?
> The second might warrant more discussion. I'd welcome text to solve
> this, because I'm not sure how it should work, in particular with
> regards to the integ_req flag. Personally, I see no point in
> supporting non-integrity authentication mechanisms -- it seems to
> weaken GS2, so I would rather drop the feature and have those
> interested in weak authentication schemes specify their own SASL
> mechanism. Further, nobody has presented a specific use-case for this
> feature, so it seems to me be feature creepism. However, text
> proposals to resolve the problem is fine.