Re: Poll: pure SCRAM versa SCRAM-as-GS2

[Hallvard B Furuseth <[e-mail]>]

Kurt Zeilenga writes:
> Draft-newman-auth-scram-gs2-00.txt contains a normative reference to
> draft-ietf-sasl-gs2-10.txt.  This implies an implementor must read and
> understand draft-ietf-sasl-gs2-10.txt, as well as elements of its
> normative references, in order to implement the protocol.  (I doubt
> this normative reference can be downgraded.)

Yes, looks like it.  That's the main problem for a non-GSS person like
me.  There might be only a small amount of GS2 semanics which needs to
be implemented, but if so it looks like I'd still have to read and
understand GS2 and GSS-API to figure that out.  OK, so I've begun to
read up on GS2 anyway, but still...

For SCRAM-GS2 to be pure-SASL friendly, what one needs to understand
about the GS2 part needs to be collected in one place.  Either in
SCRAM-GS2 or in a section of GS2, so SCRAM-GS2 can refer to just that
section.  Then the complexity argument about SCRAM-GS2 is reduced to its
technical complexity, which I don't know yet.

I would oppose a SCRAM-GS2 document which didn't do that.  OTOH it's
fine by me if the current draft is just a draft for a draft which will,
to have a poll about among those who know what the final document set
would look like.

BTW, if the GS2 folk write up that and present it for a new poll or
whatever, I'm not suggesting to put a lot of work into getting the
details right at first try.  After all comments here suggest it may
well be rejected anyway.


Regarding where to put the GS2 part, I'm staying with my original
comments.  Maybe I had picked up a bit more about GS2 than I realized.
GS2 seems to me the natural place for the normative part, maybe copied
to a SCRAM-GS2 informative section.  Of course it would be a bit better
to know what it would look like before saying that:-)

Actually complexity might be an argument _for_ placing it in GS2.
Otherwise future mechanisms that try to bridge pure SASL and GS2 must
copy or re-do that work from SCRAM.  The trick would be to make it loose
enough that it's not another layer SCRAM will exist inside, but just
some stuff SCRAM makes use of like it makes use of Base64 and HMAC.


Since SCRAM-GS2 effectively will have 2 specs which are supposed to
interoprate, I suggest to stick to the old IETF "2 implementations" rule
on this one.  Set up one pure-SASL and one GSS-API version of SCRAM-GS2
and let us see them interoperate.  If the author of the pure-SASL mech
doesn't know GS2, so much the better.


One reality check: I have no idea what kind of SASL implementations are
out there.  Are there implementations that do not support GS2/GSS?  Or
is the technical complexity a storm in a teacup because implementations
will have GS2 for the sake of Kerberos?


-- 
Hallvard