Re: Holding gs2

[Alexey Melnikov <alexey.melnikov@xxxxxxxxx>]

Simon Josefsson wrote:

> Sam Hartman <hartmans-ietf@xxxxxxx> writes:
>  
>
> > > > > > > "Simon" == Simon Josefsson <simon@xxxxxxxxxxxxx> writes:
> > > > > > >              
> >    Simon> Sam Hartman <hartmans-ietf@xxxxxxx> writes:
> >    >> I have a question for the SASL working group.  With the
> >    >> exception of the question I brought up about optimal round
> >    Simon> I fear this would delay GS2 implementations for Kerberos
> >    Simon> V5, which would give us useful feedback on other aspects of
> >    Simon> the document.
> >    
I have to admit that I share some of the concerns raised by Steve.
I think it would be nice to go through SCRAM-as-GSS-API-mechanism 
exercise before publishing GS2. However I do understand that delaying 
GS2 because of SCRAM might not be fair for people who want to try 
implement GS2.

> > Are there any implementers of SASL or Kerberos stacks who plan to delay?
> >    
> I have started to implement GS2 twice to test the Kerberos V5 reduced
> round-trip mode.  The protocol kept changing, even after passing WGLC,
> so I postponed those efforts pending a stable draft.  I recently planned
> to resume work on GS2 during February, but this discussion suggests to
> me that I need to wait longer.  Publishing GS2, with the limited
> applicability for Kerberos would move my effort forward.
>
> I'd be interested in understanding how other implementers think about
> this too.
>  
I [still] plan to implement GS2 once it is stable. But I am unlikely to 
be quicker than you in doing that, due to other commitments.

> I don't see why having three mechanisms to do the same is problematic.
> Ok, it does lead to complexity, but supposedly the complexity is
> _required_ in order to solve some identified problem.  GS2 solves the
> identified problem of unnecessary many round-trips compared to Kerberos
> V5 via GSS-API.  If we don't consider that a valid problem, we should
> say that GS2 should not be used with Kerberos V5 at all,
I consider reduction of round-trips as the main goal of GS2.

> and instead say
> that users should use GSS-API for this.  That approach would take away
> all the complexity for Kerberos in GS2.  If we go this route, I would
> support delaying publication of GS2 until we have specifications of the
> GSS-API mechanisms that were designed with GS2 in mind.
>  
How about publishing GS2 as Experimental RFC and move it (or replace it, 
if errors are found) to Standard Track once we have some implementation 
experience?

> If I recall correctly, the use-case of hybrid SASL and GSS-API
> mechanisms was established after we decided to do GS2.
>