Nicolas Williams <Nicolas.Williams at sun.com> writes: > On Mon, Oct 26, 2009 at 05:54:19PM +0100, Simon Josefsson wrote: >> <Pasi.Eronen at nokia.com> writes: >> > - Second, should Section 8 say something about the flags that are not >> > related to per-message tokens? (deleg, mutual, anon) >> >> I'm not sure what to add, but will add text if suggested. > > I think we should add something like this: > > The mutual_req_flag MUST be set. If channel binding is used then the > client MUST check that the corresponding ret_flag is set when the > context is fully establish, else authentication MUST fail. > > The first requirement is important, while the rest is, IMO, redundant -- > channel binding necessarily implies mutual authentication in the > Kerberos sense. Note that we don't require checking that mutual > authentication actually happened. Seems fine to me, added in my local copy. > And we should add something like this too: > > Use or non-use of deleg_req_flag and anon_req_flag is an > implementation-specific detail. SASL and GS2 implementors are > encouraged to provide programming interfaces by which clients may > choose to delegate credentials and by which servers may receive them. > SASL and GS2 implementors are encouraged to provide programming > interfaces which provide a good mapping of GSS-API naming options. Added too. >> > - Section 4 should say either that character case (for things like >> > "p=" and "a=") must be exactly as shown here, or that they're case >> > insensitive (if nothing is said, RFC 5234 strings are by default case >> > insensitive, I think). >> >> I added this paragraph before the ABNF: >> >> <t>The figure below describes the permissible attributes, >> their use, and the format of their values. All attribute >> names are single US-ASCII letters and are >> case-sensitive.</t> > > For the record, I don't mind if they're really case-insensitive. I would prefer to keep SCRAM and GS2 in sync here. Thanks, /Simon
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.