Transport Layer Security (TLS) Authorization Extensions
draft-housley-tls-authz-extns-09

[Ballot comment]
5. Security Considerations

  A TLS server can support more than one application, and each
  application may include several features, each of which requires
  separate authorization checks.  This is the reason that more than one
  piece of authorization information can be provided.

  A TLS server that requires different authorization information for
  different applications or different application features may find
  that a client has provided sufficient authorization information to
  grant access to a subset of these offerings.  In this situation the
  TLS Handshake protocol will complete successfully; however, the
  server must ensure that the client will only be able to use the
  appropriate applications and application features.  That is, the TLS
  server must deny access to the applications and application features
  for which authorization has not been confirmed.

s/must/MUST ? (twice)

[Ballot comment]
The abstract simply talks about "authorization information"
without giving much clue to the reader what the word means in this
context. Saying e.g. "...authorization information, such as Attribute
Certificates or SAML Assertions, ..." would make it more
understandable.

[Ballot discuss]
Updated discuss for version -08:

1) The latest version of the document changes the definition of the
"access_denied" alert (from the TLS main specification) to allow it be
non-fatal. I don't think this is a good idea. The definition in RFC
5246 is not about certificate processing, but authorization/access
control processing -- so failed authorization is already covered
there. If a new informative warning message is really needed (I don't
think it is), it should use a different number.

2) Section 2.3 says mismatched hash should result in bad_certificate
alert. Why not "bad_certificate_hash_value"?

3) Despite all the new text about alerts, the document doesn't
seem to tell what to do if downloading the URL
fails. ("certificate_unobtainable" alert -- which can be fatal or
warning -- is one obvious option)

4) Section 4 should explicitly say that all the alerts discussed here
are always fatal (except "certificate_unobtainable").

In addition, there's couple of places that probably need some
clarifications and/or minor fixes:

- Section 3.3.3 needs some references about the MIME types
(draft-ietf-pkix-attr-cert-mime-type and perhaps the IANA page or
some OASIS spec for samlassertion).

- Section 6: "For more information, see Section 6.3 of [TLS1.2]."
Should be "... Section 6.3 of [RFC4366]".

- Some of the references need updating: [SHA1] and [SHA2] have been
superseded by FIPS 180-3.

- Section 3.2, "Handshake.length = 15" should be 17 to match
the hex dump.

[Ballot comment]
RFC 2279 was obsoleted by RFC 3629.


5. Security Considerations

  A TLS server can support more than one application, and each
  application may include several features, each of which requires
  separate authorization checks.  This is the reason that more than one
  piece of authorization information can be provided.

  A TLS server that requires different authorization information for
  different applications or different application features may find
  that a client has provided sufficient authorization information to
  grant access to a subset of these offerings.  In this situation the
  TLS Handshake protocol will complete successfully; however, the
  server must ensure that the client will only be able to use the
  appropriate applications and application features.  That is, the TLS
  server must deny access to the applications and application features
  for which authorization has not been confirmed.

s/must/MUST ? (twice)

[Ballot discuss]
Updated as per draft-housley-tls-authz-extns-08.txt:

In section 2.3:

  Implementations that support either x509_attr_cert_url or
  saml_assertion_url MUST support URLs that employ the http scheme
  [UPGRADE].

If you meant "http", then the reference is incorrect. It must be
RFC 2616.
If you meant "https", then the reference should be to RFC 2818.

[Ballot comment]
The abstract and introduction simply talk about "authorization
information" without giving much clue to the reader what the word
means in this context. Saying e.g. "...authorization information,
such as Attribute Certificates or SAML Assertions, ..." would
make it more understandable.

In earlier IETF Last Call comments, I suggested increasing the
maximum lengths to more than 64K (especially SAML assertions
can be large, and there could be more than one of them). However,
investigating more, it seems using Supplemental Data message
limits us to 64K anyway. So changing the length fields in
this document wouldn't help.

[Ballot discuss]
I have reviewed draft-housley-tls-authz-extns-07, and have couple of
questions/concerns that I'd like to discuss before recommending
approval of the document. And no, none of these are related
to the process :-)

1) The document is not very clear on how these extensions apply to TLS
session resumption. Probably the intent is that if the server
decides to resume a session, these extensions (and supplemental data
messages etc.) are not used (and the authorization information comes
from the session cache). But Section 2 and 1.2 should clearly say so.

2) The document never actually says what the implementation should do
if the hash of the downloaded URL doesn't match the hash in the
message, or if downloading the URL fails. (Failing with some TLS alert
message or continuing without the authorization information would be
the obvious choices.)

3) The document should use the existing TLS HashAlgorithm IANA
registry instead of creating a new HashType registry.

4) Section 3.3.2 says the field contains "an XML-encoded "
element, but is not clear how the recipient determines the character
encoding for parsing the XML. RFC 3470 discusses several possibilities
-- the simplest of which would be just saying "MUST be UTF-8" -- but
if recipients are expected to support something more complex (BOMs,
XML declarations, etc.) the document should say so.

In addition, there's couple of places that probably need some
clarifications and/or minor fixes:

- The document says it applies to TLS 1.0 and TLS 1.1, but I'd expect
it to be version independent (applies to TLS 1.2, too -- and possibly
future versions, too).

- The hash+URL formats have a major security consideration that's not
mentioned in the document: an attacker can get the other end to fetch
any URL (which doesn't necessarily point to a certificate, and might
not be reachable by the attacker). (A one-sentence summary plus a
pointer to RFC 4366 Section 6.3 would probably be sufficient, though.)

- Section 3.2 should be clearer about what the SupplementalDataEntry
structure contains (currently, it's ambiguous whether there are one or
two 16-bit length fields after "supp_data_type" ).

- Section 2 duplicates several paragraphs worth of text from RFC
3546. That RFC has since been obsoleted, and this text has been
slightly rephrased and clarified -- but I think repeating general
description of TLS extensions (e.g. if there are multiple extensions,
they can be in any order) is not necessary here, and could be just
removed. Especially since the text uses 2119 keywords, it's not very
obvious that the "MUSTs" here are not actually new requirements.

- The document should not "Update" RFC 4346.

- The hash+URL cases probably need some additional guidance about use
of HTTP (redirects, caching, etc.). Probably a pointer to RFC 4366's
text would be sufficient for everything else than the MIME types.

- For the MIME types, it seems "application/samlassertion+xml" already
exists, and should be mentioned here. But what should be used for
attribute certificates?  Is "application/pkix-cert" only for X.509v3
PKCs?

- Some of the references need updating: [IANA] has been obsoleted by
RFC 5226 (and some of the IANA policy names changed, too).  [PKIX1]
has been obsoleted by RFC 5280.  [TLSEXT] has been obsoleted (for the
purposes of this document) by RFC 5246.  [TLSSUPP] is now RFC 4680.
[SHA1] and [SHA2] have been superseded by FIPS 180-3.

[Ballot comment]
3.3.3. URL and Hash

  Implementations that support either x509_attr_cert_url or
  saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2]
  as one-way hash functions.  Other one-way hash functions may also be
  supported.  Additional one-way hash functions can be registered in
  the future using the procedures in section 3.

I think this should point to section 4 (IANA Considerations).


5. Security Considerations

  A TLS server can support more than one application, and each
  application may include several features, each of which requires
  separate authorization checks.  This is the reason that more than one
  piece of authorization information can be provided.

  A TLS server that requires different authorization information for
  different applications or different application features may find
  that a client has provided sufficient authorization information to
  grant access to a subset of these offerings.  In this situation the
  TLS Handshake protocol will complete successfully; however, the
  server must ensure that the client will only be able to use the
  appropriate applications and application features.  That is, the TLS
  server must deny access to the applications and application features
  for which authorization has not been confirmed.

s/must/MUST ? (twice)

[Ballot discuss]
Updated after some clarifying discussions with authors:

3.3.3. URL and Hash

[...]

  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.

I believe this require a normative reference to RFC 2616, which
defines HTTP URIs.


4. IANA Considerations

  This document establishes a new registry, to be maintained by IANA,
  for TLS Authorization Data Formats.  The first four entries in the
  registry are x509_attr_cert(0), saml_assertion(1),
  x509_attr_cert_url(2), and saml_assertion_url(3).  TLS Authorization
  Data Format identifiers with values in the inclusive range 0-63
  (decimal) are assigned via RFC 2434 [IANA] Standards Action.

I understand that this is probably pedantic, but this document is targeted
for Experimental, yet it tries to assign a value in the section that
requires Standards Action. Besides, why prevent registrations of types of authorization data to Standard Track documents?
So, should this requirement be relaxed?


The same issue with Hash Types.

  Values
  from the inclusive range 64-223 (decimal) are assigned via RFC 2434
  Specification Required.  Values from the inclusive range 224-255
  (decimal) are reserved for RFC 2434 Private Use.

[Ballot comment]
3.3.3. URL and Hash

  Implementations that support either x509_attr_cert_url or
  saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2]
  as one-way hash functions.  Other one-way hash functions may also be
  supported.  Additional one-way hash functions can be registered in
  the future using the procedures in section 3.

I think this should point to section 4 (IANA Considerations).


5. Security Considerations

  A TLS server can support more than one application, and each
  application may include several features, each of which requires
  separate authorization checks.  This is the reason that more than one
  piece of authorization information can be provided.

  A TLS server that requires different authorization information for
  different applications or different application features may find
  that a client has provided sufficient authorization information to
  grant access to a subset of these offerings.  In this situation the
  TLS Handshake protocol will complete successfully; however, the
  server must ensure that the client will only be able to use the
  appropriate applications and application features.  That is, the TLS
  server must deny access to the applications and application features
  for which authorization has not been confirmed.

s/must/MUST ? (twice)

[Ballot discuss]
2.2. The server_authz Extension Type

  Clients MUST include the server_authz extension type in the extended
  client hello message to indicate their desire to receive
  authorization data from the server.

This looks like cut & paste of the first paragraph in section 2.1.
Should "client" be changed to "server" everywhere (and vice versa)?


3.3.3. URL and Hash

[...]

  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.

I believe this require a normative reference to RFC 2616, which
defines HTTP URIs.


4. IANA Considerations

  This document establishes a new registry, to be maintained by IANA,
  for TLS Authorization Data Formats.  The first four entries in the
  registry are x509_attr_cert(0), saml_assertion(1),
  x509_attr_cert_url(2), and saml_assertion_url(3).  TLS Authorization
  Data Format identifiers with values in the inclusive range 0-63
  (decimal) are assigned via RFC 2434 [IANA] Standards Action.

I understand that this is probably pedantic, but this document is targeted
for Experimental, yet it tries to assign a value in the section that
requires Standards Action. Should this requirement be relaxed?

The same issue with Hash Types.

  Values
  from the inclusive range 64-223 (decimal) are assigned via RFC 2434
  Specification Required.  Values from the inclusive range 224-255
  (decimal) are reserved for RFC 2434 Private Use.

[Ballot comment]
There seems to be a little history associated with this draft. Rather thn read up on the details I am going to Abstain. The draft seems to have enough votes to go through and I see nothing specific in the draft to object to. I am going to trust the rest of the IESG to have derived the right conclusions from history.

I am a little confused by the flopping of the status of the I-D. It seems that the most recent last call was on Standards Track, yet the I-D has now moved to Experimental (again). I gues that, since a last call was also held on that track, we don't have a problem with that.

Since the TLS working group has had no drafts and no discussions regarding authorization, I have determined that moving this document forward does not constitute an end around, and will ask the IESG to consider approving this for publication as an experimental RFC.

IANA Last Call comments:

ACTION 1:

Upon approval of this document, IANA will register the following
ExtensionType Values at
http://www.iana.org/assignments/tls-extensiontype-values

Value Extension name Reference
----- -------------- --------------------------------
7 client_authz [RFC-housley-tls-authz-extns-07.txt]
8 server_authz [RFC-housley-tls-authz-extns-07.txt]

Values 7 and 8 are currently reserved for use by this document.


ACTION 2:

Upon approval of this document, IANA will register the following
TLS SupplementalDataType at
http://www.iana.org/assignments/tls-parameters:

Value Description Reference
----- ----------- ---------
TBD authz_data [RFC-housley-tls-authz-extns-07.txt]


ACTION 3:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/tls-parameters:

Registry Name: TLS Authorization Data Formats
Range Registration Procedures
--------- -----------------------
0-63 Standards Action
64-223 Specification Required

Value Description Reference
------- ------------------------ ---------
0 x509_attr_cert [RFC-housley-tls-authz-extns-07.txt]
1 saml_assertion [RFC-housley-tls-authz-extns-07.txt]
2 x509_attr_cert_url [RFC-housley-tls-authz-extns-07.txt]
3 saml_assertion_url [RFC-housley-tls-authz-extns-07.txt]
4-223 Unassigned
224-255 Reserved for Private Use [RFC-housley-tls-authz-extns-07.txt]


ACTION 4:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/tls-parameters:

Registry Name: TLS Hash Types
Range Registration Procedures
--------- -----------------------
0-158 Standards Action
159-223 Specification Required

Value Description Reference
------- ------------------------ ---------
0 sha1 [RFC-housley-tls-authz-extns-07.txt]
1 sha256 [RFC-housley-tls-authz-extns-07.txt]
2-223 Unassigned
224-255 Reserved for Private Use [RFC-housley-tls-authz-extns-07.txt]


We understand the above to to be the only IANA Actions for this
document.

IANA Last Call comments:

Upon approval of this document, IANA will register the following:
Two new TLS extensions in
http://www.iana.org/assignments/tls-extensiontype-values

client_authz
server_authz

Values 7 and 8 are currently reserved for use by this document.

One TLS supplemental data type in
http://www.iana.org/assignments/tls-parameters:

authz_data

The IANA will also create the following new registries:

TLS Authorization Data Formats. The initial entries in the TLS
Authorization Data Formats registry will be:

0 x509_attr_cert
1 saml_assertion
2 x509_attr_cert_url
3 saml_assertion_url

TLS Hash Types. The initial entries in the TLS Hash Types registry
will be:

0 sha1
1 sha256

We understand the above to to be the only IANA Actions for this
document.

Folks, after the various IPR disclosures were filed on
draft-housley-tls-authz-extns, I asked for a second IETF last call to
see if we had consensus to publish this document on the standards
track given the IPR claims against it.

That last call did not show the consensus I was looking for.  So, we
agreed we were going to send mail to the TLS working group and ask
them for their comments on publishing the draft.  We hoped that we'd
see a consensus there.  The chairs did ask for comments; see
http://www1.ietf.org/mail-archive/web/tls/current/msg01688.html .

Comments were provided, but there was not a consensus in favor of
publication on the standards track either there or on the ietf list.

I think there is a rough consensus against publication on the
standards track.  However it is quite clear that there is not a rough
consensus in favor of publication on the standards track which would
be required to do so.

So, I am withdrawing my sponsorship of the draft and as far as the
IETF process is concerned this draft is no longer under consideration
for publication.

One option that several people suggested is publication as an
informational spec.  I personally do not choose to sponsor this
document for informational or experimental.  often, it seems that we
use informational as a way to publish things we cannot build a strong
consensus behind.  I think that process is generally problematic and
would like to avoid it in this instance.  Other ADs may consider
sponsoring this document as an informational document; I would ask
them to carefully consider whether that is the best use of the time
they have to offer the IETF community.  My conclusion is that for me
personally, it is not.

Publishing this document via the rfc editor independent submissions
track is basically not an option because the IANA assignments require
IETF consensus or standards action.


That leaves the authors with several options:

* Work with people to build consensus and try again later.  Possibly
  working on discovering prior art or trying to revise the licensing
  terms.  There should be a much higher bar for starting the process a
  second time, but perhaps that bar can be met.



* Work on an alternative that does not have the IPR constraints.

* Work on finding another AD to sponsor the document.  I will not do
  so, and I'd advise my fellow ADs to think for a long time before
  taking on this draft, but I would not block another AD sponsoring
  the draft.

* Rewrite this document as a sketch of what might be done rather than a protocol and go through the independent submissions track.

* Drop the proposal.



I'm sad that we have come to this point.  I think this technology has
significant value and wish we'd found a way to publish it.  However we
follow a consensus process for many valuable reasons and it is clear
that the necessary consensus is not present in this case.
Sam Hartman
Security Area Director

[Ballot comment]
This comment is related to the IESG discussion about references style. This document seems to propose a third style in what concerns references to RFC documents. for example a reference to RFC 2119 is not labeled as [RFC2119] or [3], but as [STDWORDS]. Moreover, the RFC numbers are not sorted, as it seems to be the current practices within the Normative References or Informative References sections. I know that we avoid having too many rules, and that we do not have consensus about a recommended style for references, still I find this confusing.

[Ballot discuss]
In Section 3.3.3, the document says:

  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.

Making this limitation at the scheme level seems odd.  It seems possible to avoid the
circular dependency by saying that clients should not advertise this extension when
using TLS in retrievals.  Are there other issues here?

IANA Comments:

Upon approval of this document, IANA will register the following:

Two new TLS extensions in the
http://www.iana.org/assignments/tls-extensiontype-values


client_authz
server_authz

One TLS supplemental data type in the registry defined in the approved document
draft-santesson-tls-supp-02.txt (location to be determined soon):

authz_data

The IANA will also create the following new registries:

TLS Authorization Data Formats. The initial entries in the TLS Authorization
Data Formats registry will be:

0 x509_attr_cert
1 saml_assertion
2 x509_attr_cert_url
3 saml_assertion_url

TLS Hash Types. The initial entries in the TLS Hash Types registry will be:

0 sha1
1 sha256