[kitten] Protocol Action: 'A set of SASL Mechanisms for OAuth' to Proposed Standard (draft-ietf-kitten-sasl-oauth-23.txt)

The IESG <iesg-secretary@ietf.org> Mon, 01 June 2015 21:50 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3244E1A00C2; Mon, 1 Jun 2015 14:50:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id aJ_aJvs02pTw; Mon, 1 Jun 2015 14:50:05 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA3F1A00CF; Mon, 1 Jun 2015 14:50:03 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150601215003.13896.68999.idtracker@ietfa.amsl.com>
Date: Mon, 01 Jun 2015 14:50:03 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/0NbhgrNOnGZCfTaaTadnGoY2oo0>
Cc: kitten mailing list <kitten@ietf.org>, kitten chair <kitten-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [kitten] Protocol Action: 'A set of SASL Mechanisms for OAuth' to Proposed Standard (draft-ietf-kitten-sasl-oauth-23.txt)
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2015 21:50:07 -0000

The IESG has approved the following document:
- 'A set of SASL Mechanisms for OAuth'
  (draft-ietf-kitten-sasl-oauth-23.txt) as Proposed Standard

This document is the product of the Common Authentication Technology Next
Generation Working Group.

The IESG contact persons are Stephen Farrell and Kathleen Moriarty.

A URL of this Internet Draft is:

Technical Summary

   OAuth enables a third-party application to obtain limited access to a
   protected resource, either on behalf of a resource owner by
   orchestrating an approval interaction, or by allowing the third-party
   application to obtain access on its own behalf.

   This document defines how an application client uses credentials
   obtained via OAuth over the Simple Authentication and Security Layer
   (SASL) to access a protected resource at a resource serve.  Thereby,
   it enables schemes defined within the OAuth framework for non-HTTP-
   based application protocols.

   Clients typically store the user's long-term credential.  This does,
   however, lead to significant security vulnerabilities, for example,
   when such a credential leaks.  A significant benefit of OAuth for
   usage in those clients is that the password is replaced by a shared
   secret with higher entropy, i.e., the token.  Tokens typically
   provide limited access rights and can be managed and revoked
   separately from the user's long-term password.

Working Group Summary

   The review process for this document was very long and complicated.
    See the shepherd write-up for details, it is comprehensive and...
    ...long... but ends with:
   The fourth WGLC achieved consensus with support from both kitten and
   the oauth working groups.  It did result in a few clarifications to
   the document, fixing the ABNF and examples, noting the generic SASL 
   cancellation token functionality, and reiterating the TLS requirements
   for using this mechanism, but these changes were not controversial.

Document Quality

  The long gestation period here has resulted in pretty high
  quality documentation of this not that hard to understand
  combination of schemes. I'm not sure about implementation

   The document shepherd is Benjamin Kaduk.  The responsible Area 
   Director is Stephen Farrell.