Review of draft-ietf-tls-authz-extns-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



SUMMARY
I do not believe this document should be advanced to Proposed Standard
at this time. First, it is not clear that there is really sufficient
interest in this document to justify it being at the PS level. Second,
despite several revisions to the RedPhone IPR disclosure, the IPR
status of this document remains unclear. Finally, there are technical
issues that should be fixed before the document advances at all.


BACKGROUND
This document was originally brought to the TLS WG, which expressed
little interest in it. It was subsequently sponsored as an individual
submission by then SEC AD Sam Hartman and approved by the IESG. 

Subsequent to IESG approval, one of the authors (Brown) filed an IPR
statement
(https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=765)
that claims to cover the technology. The listed terms were RAND but not
necessarily royalty-free. The IESG rescinded the approval of this
document and sent it back to last call. In the interim, two other IPR
statements have been filed, one by Stephen Farrell on work that he did
and a third party disclosure one by Eric Rescorla on some IBM
work. In the subsequent last call, there was not wide support
for the document and it was not approved. Recently, Brown revised
his IPR statement to assert that at least some usages of this 
draft are not covered by the relevant patent application
(https://datatracker.ietf.org/ipr/1026/) and that encumbered
usages would be subject to RAND licensing, leading to this fourth
last call.


IPR ISSUES
IMHO the IPR situation is substantially less clear than it has
been made out to be. First, there is is not one but three 
IPR disclosures, with the other two relating to Siemens and IBM. As
I stated in my previous review, I'm not too worried about the
IBM IPR, but the Siemens one is less available and it's harder
to evaluate, though the inventor, Steve Farrell says he thinks
it may not apply.

That still leaves the RedPhone IPR. As I indicated above,
the current IPR statement asserts that only some uses of this
document, not the document itself, are covered by the 
relevant patent application:

    RedPhone Security hereby asserts that the techniques for sending and
    receiving authorizations defined in TLS Authorizations Extensions
    (version draft-housley-tls-authz-extns-07.txt) do not infringe upon
    RedPhone Security's intellectual property rights (IPR). This statement
    applies only to the IETF Document draft-housley-tls-authz-extns-07.txt
    (hereafter the "Protocol Document").

    The values provided in, and the processing required by the
    authorizations ("authz_data" in the Protocol Document) sent or
    received using the techniques defined in TLS Authorizations Extensions
    are not specified in the Protocol Document. When an implementation
    generates the authorizations or processes these authorizations in any
    of the four ways described below, then this practice may be covered by
    RedPhone Security's patent claims.

I have two concerns here. First, it is not clear to me that the 
four listed ways don't actually implicate a significant fraction
of the space. In particular, one very natural use of authorization
data is in coordination with legal agreements. However, this is 
specifically two of the four listed covered uses:

    2. To store Agreements and locate Agreements based on authorization
    data received from a sender, where Agreements are any legally
    recognizable and documented agreement between two parties, including,
    without limitation (a) agreements between governing bodies
    (e.g. treaties, memoranda of understanding), (b) agreements created by
    governing bodies (e.g. laws, edicts, orders), and (c) other agreements
    enforceable by governing bodies (e.g. contracts, negotiable
    instruments).
    
    3. To compare the sender of authorization data to a stored collection
    of Agreement signers.

So, in practice, many useful applications of this document are in
fact encumbered.

More troubling, however, is potential encumbrances outside of these
four uses. The assertion by RedPhone is just that, an assertion.  It
is not a license grant. If I implement the protocol described in this
document, I would still be vulnerable to an infringement suit by
RedPhone even if I did not use it in any of the four listed
ways. RedPhone would simply have to assert that upon reexamining the
patent it had concluded that the scope was more general than they had
previously sought. All RedPhone's assertion buys me is a defense
against willful infringement. To sharpen this point, consider the case
where RedPhone sold the patent to some other entity which then decided
to file suit.  This is not a purely theoretical worry. While I have
not studied the patent, a number of the claims seem rather broader
than what is described above and quite possibly cover all uses of the
protocol described in this document.


TECHNICAL ISSUES
S 3.3.
As Simon Josefsson notes, the length of the SAMLAssertion
should allow up to 2^24 or 2^32 bytes. As far as I know,
the only objection to this is backward compatibility.

S 3.3.1
I'm quite concerned about the use of entityName field to bind an AC to
a certificate. In the absence of Internet-wide name subordination,
there may be many certificates with the same DN issued by different
CAs. As the issuer of an AC, I generally want to authorize specific
entities, not "anyone who has a DN that chains to one of the 150
roots in your browser". I would remove this option entirely.


S 3.3.
This URLandHash production has a nasty futureproofing bug, because the
length isn't self-contained. If the server uses a hash the consumer
doesn't recognize, the consumer can't even parse the rest of the
extension, even if it contains other AuthorizationDataEntry objects
which the client could otherwise parse and which would in and
of themselves be sufficient. The URLandHash production should
either have a length or have the hash be a variable length value,
e.g., opaque hash<0..255>. This would allow parsing even if you
don't know the hash.


S 3.3.3
This circular reference issue seems bogus to me. There are
lots of places where it's not going to be relevant, and 
SHOULD is overstrong.


S 4.
This document should use the RFC 5246 hash registry (and its
contents), not define its own. Note that the values in that
registry differ from those in this draft.


EDITORIAL ISSUES
S 2.
The beginning of this section needs to be clearly marked as
non-normative, since it's just a recap of 4366.

S 3.
"can be exchanges" -> "can be exchanged"

-Ekr

























_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]