Protocol Action: 'Transport Layer Security (TLS) Authorization Extensions' to Proposed Standard

[The IESG <iesg-secretary at ietf.org>]

The IESG has approved the following document:

- 'Transport Layer Security (TLS) Authorization Extensions '
   <draft-housley-tls-authz-extns-07.txt> as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Sam Hartman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-housley-tls-authz-extns-07.txt

Technical Summary
 
   This document specifies authorization extensions to the Transport
   Layer Security (TLS) Handshake Protocol.  Extensions carried in the
   client and server hello messages to confirm that both parties support
   the desired authorization data types.  Then, if supported by both the
   client and the server, authorization information is exchanged in the
   supplemental data handshake message.

 
Working Group Summary
 
   This document is not the product of the TLS working group but has
   been review there.  Changes were made to address comments. 
 
Protocol Quality
 
This specification has been reviewed for the IESG by Sam Hartman.




Note to RFC Editor

  Please replace the first paragraph of section 3.3.2:

  OLD:

   When SAMLAssertion is used, the field contains an XML-encoded
   <Assertion> element using the AssertionType complex type as defined
   in [SAML1.1][SAML2.0].  SAML is an XML-based framework for exchanging
   security information.  This security information is expressed in the
   form of assertions about subjects, where a subject is either human or
   computer with an identity.  In this context, the SAML assertions are
   most likely to convey authentication or attribute statements to be
   used as input to authorization policy governing whether subjects are
   allowed to access certain resources.  Assertions are issued by SAML
   authorities.

  NEW:

   When SAMLAssertion is used, the field MUST contain well-formed
   XML [XML1.0] and MUST use either UTF-8 [UTF-8] or UTF-16 [UTF-16]
   character encoding.  UTF-8 is the preferred character encoding.  The
   XML text declaration MUST be followed by an <Assertion> element using
   the AssertionType complex type as defined in [SAML1.1][SAML2.0].
   The XML text MUST also follow the rules of [XML1.0] for including
   the Byte Order Mark (BOM) in encoded entities.  SAML is an XML-based
   framework for exchanging security information.  This security
   information is expressed in the form of assertions about subjects,
   where a subject is either human or computer with an identity.  In
   this context, the SAML assertions are most likely to convey
   authentication or attribute statements to be used as input to
   authorization policy governing whether subjects are allowed to
   access certain resources.  Assertions are issued by SAML authorities.

  Please replace the second paragraph of section 3.3.3:

  OLD:

   Implementations that support either x509_attr_cert_url or
   saml_assertion_url MUST support URLs that employ the http scheme.
   Other schemes may also be supported; however, to avoid circular
   dependencies, supported schemes SHOULD NOT themselves make use of
   TLS, such as the https scheme.

  NEW:

   Implementations that support either x509_attr_cert_url or
   saml_assertion_url MUST support URLs that employ the http scheme.
   Other schemes may also be supported.  When dereferencing these
   URLs, circular dependencies MUST be avoided.  Avoiding TLS when
   dereferencing these URLs is one way to avoid circular dependencies.
   Therefore, clients using the HTTP scheme MUST NOT use these TLS
   extensions if UPGRADE in HTTP [UPGRADE] is used.  For other schemes,
   similar care must be used to avoid using these TLS extensions.

  Please add three normative references:

  NEW:

   [UPGRADE]    Khare, R., and S. Lawrence, "Upgrading to TLS Within
                HTTP/1.1", RFC 2817, May 2000.

   [UTF-8]      Yergeau, F., "UTF-8, a transformation format of
                ISO 10646", RFC 2279, January 1998.

   [UTF-16]     Hoffman, P. and F. Yergeau, "UTF-16, an encoding of
                ISO 10646", RFC 2781, February 2000.


_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce