Subject: Re: [kitten] WG Adoptions

From: Simon Josefsson <[email-masked]>
Date: Fri, 12 Nov 2010 22:24:53 +0100

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.

/Simon

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 12 Nov 2010 16:34:10 -0500

> involved?  That is open ended.

I don't think it needs to be open ended, I interpreted it as saying that
mechanisms that provide (or don't provide) particular security guarantees
should be required to say so. The WG should be able to enumerate a set of
such guarantees that are useful and just ask that the SC sections address
them.

Another way of saying it is, let's aspire to consistency in the SC material
across all these mechanisms so that people can evaluate apples to apples.
 
-- Scott

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 12 Nov 2010 17:01:41 -0500

> involved?  That is open ended.

Indeed.  I think we all agree that security considerations for each 
mechanism need to be appropriately documented before we can publish.  That 
does not mean it must or should be done before we adopt; after all, that's 
part of the work we're signing on to do.

> but if that is what people want, I think it should be explicit.

Again, I think we have general agreement in this WG that SASL and GSS-API 
mechanisms should include CB support whenever feasible.  Thus, any time we 
adopt a mechanism, it's pretty much a given that we're going to try to make 
sure it has CB support.  I'd be very surprised if, having adopted a 
mechanism, we found rough consensus to approve it without CB support when 
adding such support is doable.  On the other hand, I wouldn't be surprised 
if we published a document defining mechanism for which CB support is not 
feasible, given sufficient need.  Certainly I think we'd publish PLAIN 
today.

> from people to work on the documents, and to review them.  There is even

I'm inclined to agree.  I've never been a fan of "late adoption"; if we 
believe this work is worth doing, we should adopt it now and then do it, 
rather than expecting it to be done before we adopt.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 13 Nov 2010 09:41:26 +0100

> across all these mechanisms so that people can evaluate apples to apples.

I would support that, but I'm not certain that interpretation is the
only one that is being made.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 13 Nov 2010 09:51:08 +0100

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?  It may be a bit early though, there
haven't been that many interop of CB-enabled implementations, let alone
deployment...

/Simon