Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07

Melinda Shore <mshore@cisco.com> Fri, 13 February 2009 14:38 UTC

Return-Path: <mshore@cisco.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8D2E3A6BE0; Fri, 13 Feb 2009 06:38:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0GFlgFtIMew; Fri, 13 Feb 2009 06:38:25 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BD10A3A67F7; Fri, 13 Feb 2009 06:38:24 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.38,202,1233532800"; d="scan'208";a="36950029"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Feb 2009 14:38:30 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1DEcURs019577; Fri, 13 Feb 2009 09:38:30 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1DEcUqS025907; Fri, 13 Feb 2009 14:38:30 GMT
Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 09:38:30 -0500
Received: from 10.98.54.215 ([10.98.54.215]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Feb 2009 14:38:30 +0000
User-Agent: Microsoft-Entourage/12.0.0.071130
Date: Fri, 13 Feb 2009 09:38:29 -0500
Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07
From: Melinda Shore <mshore@cisco.com>
To: Josh Howlett <Josh.Howlett@ja.net>
Message-ID: <C5BAF015.334D%mshore@cisco.com>
Thread-Topic: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07
Thread-Index: AcmNOUsifPOne/+8RcqFVJ7RSjvsDAAA9ChwAAH+vPcAAFRa0AAEND6wACRg1lE=
In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB04CD3CC5@uxsrvr20.atlas.ukerna.ac.uk>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 13 Feb 2009 14:38:30.0819 (UTC) FILETIME=[BD832F30:01C98DE8]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1165; t=1234535911; x=1235399911; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20<mshore@cisco.com> |Subject:=20Re=3A=20[TLS]=20TLS=20WG=20Chair=20Comments=20o n=20draft-ietf-tls-authz-07=20 |Sender:=20 |To:=20Josh=20Howlett=20<Josh.Howlett@ja.net>; bh=rvDGb4GmAEcdRUT66FmsKEZfpxdGTb8yZavvD+abOzQ=; b=C3XNQoc8jT00lg3i/b3y0UUKzyPO8enJF6aEHpmcHUay2QhgiulpRngj+o G4TPwYdpido44Ge64mJmUdR8JQWGGy5GqidKt/ydIHPq8i+VdGxOIeU75VEi QQ80DjBn+Y;
Authentication-Results: rtp-dkim-1; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Cc: tls@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Feb 2009 14:38:26 -0000

On 2/12/09 4:47 PM, "Josh Howlett" <Josh.Howlett@ja.net> wrote:
> I have a long list of applications, collected from within this
> community, with which they would like to use SAML-based authorisation;
> and it seems to me that the ability for application protocols to share a
> common mechanism for expressing authorisation would mitigate or perhaps
> even avoid the need to make application-specific authorisation
> extensions.

Right, and to be more specific about it, the kinds of
things that we're talking about include reducing retained
state on devices during the authorization process by
eliminating queries, reducing the problems around service
discovery and topology, and I tend to think that there
are some cross-domain advantages, as well.  There are
fate-sharing considerations, where the authorizations
aren't held by devices that don't need them, they're not
delivered if the traffic isn't delivered, and if the
traffic is delivered the authorizations are delivered.
So, I think that in addition to some issues specific
to authorization problems there are some advantages
around traditional networking considerations.

Melinda