Subject: Re: [kitten] WG Adoptions

From: Alexey Melnikov <[email-masked]>
Date: Sat, 04 Dec 2010 12:38:41 +0000

Simon Josefsson wrote:

>Jeffrey Hutzelman <[email-masked]> writes:
>  
>
>>Again, I think we have general agreement in this WG that SASL and
>>GSS-API mechanisms should include CB support whenever feasible.
>>    
>>
>People who have been participating here for a long while would probably
>agree, but I'm not sure we have that written down anywhere and I think
>newcomers are struggling with the motivation for CB in SASL.  Maybe a
>"SASL/GSS-API Mechanism Design Best Practice" document or similar would
>help.  Or just updated RFC 4422?
>
Either one would be really appreciated.

>It may be a bit early though, there
>haven't been that many interop of CB-enabled implementations, let alone
>deployment...
>  
>

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 04 Dec 2010 12:39:53 +0000

Simon Josefsson wrote:

>Shawn M Emery <[email-masked]> writes:
>  
>
>>This starts a WG consensus call for the adoption of two new work items
>>to the charter:
>>
>>SASL-SAML-EC
>>http://tools.ietf.org/html/draft-cantor-ietf-kitten-saml-ec
>>
>>SASL-OAuth:
>>http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth
>>
>>1. Adopt with no pre-conditions
>>2. Adopt with the assumption that there be a CB option specified for
>>each mechanism
>>3. Adopt after the security considerations/assumptions of each
>>mechanism is fully understood
>>4. Both 2 and 3.
>>    
>>
>Option 3 seemed reasonable to me, since I believe that it is critical
>for the 'Security Considerations' for each document to be accurate and
>understandable.  The problem with the option is when to evaluate the
>status, and how to do it -- what does it mean for something to be "fully
>understood"?  Do we check that every WG participant understands what is
>involved?  That is open ended.
>
>Option 2 looks good from a security perspective, and it is doable for
>SAML20EC.  However, for SASL-OAuth I don't see a way to implement a CB
>option, thus what 2 would translate into is that we refuse to adopt the
>document?  This just means that it will proceed on a individual basis,
>and be registered in the SASL registry, without any opportunity for the
>Kitten WG to influence its design.  I don't care strongly either way,
>but if that is what people want, I think it should be explicit.
>
>Thus I am leaning towards option 1 because it will allow the WG to
>improve the documents into something good, or perhaps more correct: as
>good as it possible can become.  There seems to be sufficient interest
>from people to work on the documents, and to review them.  There is even
>new blood in the WG.
>
>The output documents still has to pass IETF-wide review, and if there is
>a strong community concern on the issues implied by option 2+3, I'm sure
>we'll hear about it.
>  
>
I know that I am several weeks late, but in case people want to know my 
opinion: +1 to what Simon said here.