RE: [TLS] Authorization extension test server available
Ari Medvinsky <arimed@windows.microsoft.com> Thu, 22 February 2007 16:53 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKHBl-0003vs-9e; Thu, 22 Feb 2007 11:53:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKHBj-0003vn-QT for tls@ietf.org; Thu, 22 Feb 2007 11:52:59 -0500
Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKHBg-0007aZ-DM for tls@ietf.org; Thu, 22 Feb 2007 11:52:59 -0500
Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 22 Feb 2007 08:52:55 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.685.25; Thu, 22 Feb 2007 08:52:55 -0800
Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Thu, 22 Feb 2007 08:52:55 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Authorization extension test server available
Date: Thu, 22 Feb 2007 08:50:27 -0800
Message-ID: <802A881C87166D4597F9EEFC3F04F4F8041401AF@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <E1HKGVH-000286-PH@megatron.ietf.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Authorization extension test server available
Thread-Index: AcdWnCL/nElka6/rTlK7fD4ze4JcegABOSeQ
References: <87tzxeilse.fsf@latte.josefsson.org> <E1HKGVH-000286-PH@megatron.ietf.org>
From: Ari Medvinsky <arimed@windows.microsoft.com>
To: Russ Housley <housley@vigilsec.com>, Simon Josefsson <simon@josefsson.org>, tls@ietf.org
X-OriginalArrivalTime: 22 Feb 2007 16:52:55.0285 (UTC) FILETIME=[E60F8A50:01C756A1]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org
It is a good idea to increase the size for SAML to be more then 64k - note that just the XML Dig Sig on a SAML assertion is around 16K; then within the SAML assertion you can have any number of attribute statements, etc. Ari Medvinsky Sr. Program Manager Windows Security -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Thursday, February 22, 2007 8:02 AM To: Simon Josefsson; tls@ietf.org Subject: Re: [TLS] Authorization extension test server available Simon: >Hi all! GnuTLS now supports the TLS authorization extension, and I'm >wondering if anyone is interested in interop testing of this feature? > >Our public test server supports RFC 4680 and >draft-housley-tls-authz-extns-07 in case someone wants to point their >clients towards a server: > >http://www.gnu.org/software/gnutls/server.html Very cool. >It may be too late to change the specifications, but my comments after >implementing this were: > >- The size of authorization data, i.e., X.509 attribute certs and SAML > assertions, are limited to 64kb. Is it certain that we won't need > more? I have little experience with SAML, but 64K is a lot of space for attribute certificates. >- There is no discussion on authorization failures. Should the > handshake be aborted? This is complicated by the fact that the > authorization data is sent _before_ authentication data. Typically > you wait until authentication is complete before processing > authorization data. We discussed this while developing the specification. The current document is the cleanest way to use the extension mechanism that we could devise. And, no one offered a better alternative during the review process. Of course, implementation and deployment experience may show us a better way. If the authorization requirements are not satisfied, then the TLS session should be shutdown. I would expect the access_denied fatal alert to be used. Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] Authorization extension test server availab… Simon Josefsson
- Re: [TLS] Authorization extension test server ava… Russ Housley
- RE: [TLS] Authorization extension test server ava… Ari Medvinsky