Re: [kitten] Fwd: [Technical Errata Reported] RFC5801 (2825)

Shawn M Emery <shawn.emery@oracle.com> writes:

> On 11/12/11 7:27 PM, Stephen Farrell wrote:
>> Folks,
>>
>> Not being on the top of anyone's list, this doesn't
>> seem to have progressed since June.
>>
>> Can we resolve this on the list or at this week's
>> meeting?
>
> Let's discuss this during the session.
>
> Simon,
>
> What was the result of your tests running against the updated version
> of GNU SASL?

I must admit that I forgot about this.  GNU SASL still populate the
initiator-address-type and acceptor-address-type fields to 0.

Did any other implementers experiment with changing this?

I'm a bit uncertain how to test this properly, just modifying GNU SASL
to use 0 instead of 255 will likely work running against itself, but the
bigger question is probably if any interoperability between the old
variant and the new variant is affect, and if the choice of GSS-API
library has any bearing of the outcome.  Or even GS2 implementation.

I still agree that it is a bug in the specification though.  If you want
to see a resolution to this errata report now, I suggest to approve it
and we'll figure out if there are any interop issues later on.  You can
always update the errata later on if that turns out to be the case.

/Simon

> Shawn.
> --
>> On 06/08/2011 11:02 AM, Stephen Farrell wrote:
>>>
>>>
>>> On 08/06/11 09:02, Simon Josefsson wrote:
>>>> Stephen Farrell<stephen.farrell@cs.tcd.ie>  writes:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Can you confirm that this is correct, or not?
>>>>
>>>> I think we could use some more discussion before approving this -- for
>>>> example, what impact does this have on existing implementations?
>>>
>>> Good point. I'm fine with waiting for the WG to give me the
>>> answer that I'll cut'n'paste into the errata tool:-) Sooner
>>> is of course better for that.
>>>
>>> Thanks,
>>> S.
>>>
>>>>
>>>> I will try to change my implementation to use 255 instead of 0 and see
>>>> if it still works and inteoperates with my old version.  It would be
>>>> useful if others could do similar experiments.  I don't expect serious
>>>> problems, but I think we should consider the impact before approving
>>>> this.
>>>>
>>>> I do agree it is a bug in the specification though.
>>>>
>>>> /Simon
>>>>
>>>>> Thanks,
>>>>> S.
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject: [Technical Errata Reported] RFC5801 (2825)
>>>>> Date: Tue,  7 Jun 2011 20:58:20 -0700 (PDT)
>>>>> From: RFC Errata System<rfc-editor@rfc-editor.org>
>>>>> To: simon@josefsson.org, Nicolas.Williams@oracle.com,
>>>>> stephen.farrell@cs.tcd.ie, turners@ieca.com, tlyu@mit.edu,
>>>>> kurt.zeilenga@isode.com
>>>>> CC: thomas.maslen@quest.com, rfc-editor@rfc-editor.org
>>>>>
>>>>>
>>>>> The following errata report has been submitted for RFC5801,
>>>>> "Using Generic Security Service Application Program Interface
>>>>> (GSS-API)
>>>>> Mechanisms in Simple Authentication and Security Layer (SASL): The GS2
>>>>> Mechanism Family".
>>>>>
>>>>> --------------------------------------
>>>>> You may review the report below and at:
>>>>> http://www.rfc-editor.org/errata_search.php?rfc=5801&eid=2825
>>>>>
>>>>> --------------------------------------
>>>>> Type: Technical
>>>>> Reported by: Thomas Maslen<thomas.maslen@quest.com>
>>>>>
>>>>> Section: 5.1
>>>>>
>>>>> Original Text
>>>>> -------------
>>>>> The initiator-address-type and acceptor-address-type fields of the
>>>>> GSS-CHANNEL-BINDINGS structure MUST be set to 0.
>>>>>
>>>>>
>>>>> Corrected Text
>>>>> --------------
>>>>> The initiator-address-type and acceptor-address-type fields of the
>>>>> GSS-CHANNEL-BINDINGS structure MUST be set to 255 (GSS_C_AF_NULLADDR).
>>>>>
>>>>>
>>>>> Notes
>>>>> -----
>>>>> See RFC 2744, section 3.11, last paragraph:  "[...] or omit addressing
>>>>> information, specifying GSS_C_AF_NULLADDR as the address-types".
>>>>>
>>>>> Appendix A of RFC 2744 specifies that the value of
>>>>> GSS_C_AF_NULLADDR is 255.
>>>>>
>>>>> Instructions:
>>>>> -------------
>>>>> This errata is currently posted as "Reported". If necessary, please
>>>>> use "Reply All" to discuss whether it should be verified or
>>>>> rejected. When a decision is reached, the verifying party (IESG)
>>>>> can log in to change the status and edit the report, if necessary.
>>>>>
>>>>> --------------------------------------
>>>>> RFC5801 (draft-ietf-sasl-gs2-20)
>>>>> --------------------------------------
>>>>> Title               : Using Generic Security Service Application
>>>>> Program
>>>>> Interface (GSS-API) Mechanisms in Simple Authentication and Security
>>>>> Layer (SASL): The GS2 Mechanism Family
>>>>> Publication Date    : July 2010
>>>>> Author(s)           : S. Josefsson, N. Williams
>>>>> Category            : PROPOSED STANDARD
>>>>> Source              : Simple Authentication and Security Layer
>>>>> Area                : Security
>>>>> Stream              : IETF
>>>>> Verifying Party     : IESG
>>>>
>>> _______________________________________________
>>> Kitten mailing list
>>> Kitten@ietf.org
>>> https://www.ietf.org/mailman/listinfo/kitten
>>>
>> _______________________________________________
>> Kitten mailing list
>> Kitten@ietf.org
>> https://www.ietf.org/mailman/listinfo/kitten