Subject: Re: [TLS] Comments on draft-housley-tls-authz-extns-07

From: Dean Anderson <[email-masked]>
Date: Fri, 8 Jun 2007 16:50:23 -0400 (EDT)

On Wed, 30 May 2007, Sam Hartman wrote:

> >>>>> "Dean" == Dean Anderson <[email-masked]> writes:
> 
>     Dean> I believe the IETF announced that it would be sending this
>     Dean> draft back to the 'starting gate'.  To me, that means that
>     Dean> TLS has to do several things:
> 
> Dean, Eric has corrected your statements about where this draft is in
> the process.  

Yes. I have to say, I'm not too happy about that, and am feeling misled
yet again.  I expected more effort than just posting an email requesting
comment to the TLS working group. I understood the TLS working group was
going to do some work on the draft to find out if the patented standard
is actually worth the trouble, and __approve__ or __reject__ the draft
independently of the IESG.  What is actually happening is less even than
a rubber-stamp. (a rubber stamp is -some- approval)

It seems your rubber-stamp process does not permit enough time to come
up with an alternative, nor is there any working group to work on doing
so.  It seems the deck is stacked for no change.

>     Dean> 1) Consider non-patented alternatives in accordance with
>     Dean> RFC2418 and RFC3979.
> 
> Dean, this is an excellent idea. Anyone who wants to including you can
> discuss alternatives to the technology. The availability of other ways
> to do this--particularly when combined with information about whether
> people are willing to do the necessary work to write up and implement
> these alternatives--would be great input to the IESG. I'd appreciate
> anything you can do in this regard.

To what working group should I take this work to?  Not TLS, it hasn't
agreed (has affirmatively refused) to take on this work.

> As an example, if all the implementers say that they prefer this
> solution to alternatives they have considered, and would implement
> this solution but not those alternatives, that would be a strong
> argument in favor of publication.  If on the other hand people say
> that they would write up an alternative and that they would implement
> the alternative, that would argue against publication.

No working group will consider conducting this work.

> What you may be assuming is that we have an obligation to conduct such
> a review or that we need to block our work until such a review is
> done.  

I think that RFC3979 includes an obligation to conduct such a review
even if cursory. I rather agree that RFC3979 needs further refinement on
the effort required in general and timing of the effort required.  

But in the present cirumstances, I think the scandal imposes an
obligation to __thoroughly__ review the matter; that means some kind of
notable, significant work at review must be done.  We need more than a
whitewash.

> so if you want to propose an alternative, you should do so.  If you
> know others who want to propose an alternative you should encourage
> them.

Yes, I do. Where should I tell them to go?  This subject is off-topic
for TLS after the chair refuses to take up the subject.  You can't have
it both ways; unless you _want_ a whitewash.

You've officially asked for comments, but this group refuses to do any
work on the matter.  A convenient conundrum; A catch-22.  And when no
work gets done, you "don't have to wait around before re-approving".  
That is a charade; A sham; A debacle.

> That's why we are soliciting comments.  The ietf list discussion was
> in the minds of some inconclusive.

Actually, I think it was ended in the premise that the TLS working group
would work on the document, and there is nothing to discuss until that
is done.

> We're soliciting review here in hopes that the discussion will lead to
> a clear consensus.

And how is anyone outside the IESG to know there was a clear consensus?  
No working group has worked on the tainted document, to remove the taint
of the previous IESG scandal.

>     Dean> 3) Pass a working group last-call, per RFC2026 and RFC2418.
> 
> Not applicable because this is not a WG document.

I think it _should_be_ made a working group document, and that someone
besides the IESG should put some effort into reviewing the document,
before it submitted back to the IESG.

This process, as it is, seems to be a sham. If I knew that earlier, I
would have said that to the IETF list; but I believed that you (Sam
Hartman) would ensure a proper thorough review.  

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: <[email-masked]>
Date: Mon, 11 Jun 2007 12:02:10 +0300

Dean Anderson wrote:

> > Dean, this is an excellent idea. Anyone who wants to including you
> > can discuss alternatives to the technology. The availability of
> > other ways to do this--particularly when combined with information
> > about whether people are willing to do the necessary work to write
> > up and implement these alternatives--would be great input to the
> > IESG. I'd appreciate anything you can do in this regard.
> 
> To what working group should I take this work to?  Not TLS, it 
> hasn't agreed (has affirmatively refused) to take on this work.

Dean: as you well know, most WG documents start as individual
Internet-Drafts. This way, the WG has something concrete to read 
when considering whether to take on the work as WG item or not.

Currently, no such draft exists. If, however, someone would write 
such a draft, and ask the TLS WG to consider adopting it as WG 
item, we would certainly consider it. Or yet in other words: 
there certainly is *NO* blanket decision to refuse all work
in this area.

<snip>
> No working group will consider conducting this work.

Let's not forget that *all* work in IETF is done by people,
not working groups. If nobody cares about this topic enough to 
actually write a document and drive it forward, the question 
of whether it should be WG item or not doesn't really apply.

Best regards,
Pasi

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 11 Jun 2007 11:45:42 +0200

> there certainly is *NO* blanket decision to refuse all work

The problem is, as far as I can tell, that the patent covers the general
idea of (some aspects) of authorization with X.509 Attribute
Certificates over the TLS protocol.

Thus, any draft that transfer X.509 Attribute Certificates over TLS will
have the same concern with regards to this particular patent.

Finding a way to route around the patent seems challenging, but given
the current license terms, it may still be the simplest solution.
Finding prior art for widely useful scenarios should be easy.  One
solution would be to write a draft that specify a similar protocol, and
document several use-cases with references to prior art.

If someone knows of prior art where X.509 Attribute Certificates and/or
SAML assertions are sent over TLS (possibly in the handshake, but that
doesn't seem critical), that would be very useful information.

/Simon

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 11 Jun 2007 12:54:05 +0200

> doesn't seem critical), that would be very useful information.
Hi Simon, 

You could probably find some prior art -was a TLS WG item- (published by Stephen Farrell, 1998) at http://tools.ietf.org/html/draft-ietf-tls-attr-cert-00 and http://tools.ietf.org/html/draft-ietf-tls-attr-cert-01

The minor difference is that by 1988, the TLS Extensions wasn't published yet.

Best regards,

Badra

---

From: Sam Hartman <[email-masked]>
Date: Sun, 10 Jun 2007 21:30:19 -0400

Dean> I believe the IETF announced that it would be sending this
    Dean> draft back to the 'starting gate'.  To me, that means that
    Dean> TLS has to do several things:
    >>  Dean, Eric has corrected your statements about where this
    >> draft is in the process.

    Dean> Yes. I have to say, I'm not too happy about that, and am
    Dean> feeling misled yet again.  I expected more effort than just
    Dean> posting an email requesting comment to the TLS working
    Dean> group. I understood the TLS working group was going to do
    Dean> some work on the draft to find out if the patented standard
    Dean> is actually worth the trouble, and __approve__ or __reject__
    Dean> the draft independently of the IESG.  What is actually
    Dean> happening is less even than a rubber-stamp. (a rubber stamp
    Dean> is -some- approval)
It would be great if members of the TLS working group would do the
work of determining  "whether the patented standard is worth the trouble."
I cannot force them to do the work.
I can consider how much work gets done  when I evaluate the comments tomorrow.

    Dean> It seems your rubber-stamp process does not permit enough
    Dean> time to come up with an alternative, nor is there any
    Dean> working group to work on doing so.  

I'd certainly take comments from specific parties claiming to be
dedicating effort to developing or exploring alternatives very
seriously.  I.E. I'm not going to take a claim that "someone should
explore alternatives" all that seriously.  I would take a claim that
"Alice, Bob and two of their friends are working on exploring
alternatives and request a month to do so," as very interesting.  I'd
take a claim that "Alice and bob are working on writing up the
following alternative; they should be done with a 00 draft within x
months after Chicago" as even more interesting input.

    >>  Dean, this is an excellent idea. Anyone who wants to including
    >> you can discuss alternatives to the technology. The
    >> availability of other ways to do this--particularly when
    >> combined with information about whether people are willing to
    >> do the necessary work to write up and implement these
    >> alternatives--would be great input to the IESG. I'd appreciate

    Dean> To what working group should I take this work to?  Not TLS,
    Dean> it hasn't agreed (has affirmatively refused) to take on this
    Dean> work.

The tls mailing list is a fine place to have the initial discussion.
If you get to a draft and the TLS working group declines the draft,
then we could follow the standard procedure for bringing new work to
the IESG.  You'd presumably ask me to sponsor your draft as an
individual submission.  I might decide that a BOF was more
appropriate, or I might try and pressure the TLS working group into
accepting the work.  At this stage though getting a concrete proposal
on the table is the clear first step.

    >> so if you want to propose an alternative, you should do so.  If
    >> you know others who want to propose an alternative you should
    >> encourage them.

    Dean> Yes, I do. Where should I tell them to go?  This subject is
    Dean> off-topic for TLS after the chair refuses to take up the
    Dean> subject.  You can't have it both ways; unless you _want_ a
    Dean> whitewash.

The tls list.

    Dean> You've officially asked for comments, but this group refuses
    Dean> to do any work on the matter.  A convenient conundrum; A
    Dean> catch-22.  And when no work gets done, you "don't have to
    Dean> wait around before re-approving".  That is a charade; A
    Dean> sham; A debacle.

    >> That's why we are soliciting comments.  The ietf list
    >> discussion was in the minds of some inconclusive.

    Dean> Actually, I think it was ended in the premise that the TLS
    Dean> working group would work on the document, and there is
    Dean> nothing to discuss until that is done.

That is not my understanding.

Thanks for your input,

--Sam

---

From: Dean Anderson <[email-masked]>
Date: Mon, 11 Jun 2007 16:56:13 -0400 (EDT)

> there certainly is *NO* blanket decision to refuse all work

One draft already exists: Housleys. And the working group will not work
on that draft, even after scandal compels interest. So why would anyone
expect it will work on another draft on the same subject? Kind of hard
to motivate people to put in work, when the group has already said it
won't take up the subject.

Most all decisions are subject to future review and reversal. But many
people look at past decisions for a clue to future decisions.

> of whether it should be WG item or not doesn't really apply.

We have one document. Maybe two.

Actually, I note that the TLS March '06 minutes for the discussion of
the housley draft say:

"A show of hands indicated that while a number of people are interested 
in this item, only two were interested enough to agree to review the 
document and comment. Thus, this item will continue as an individual 
item."

In some other groups, this would be enough interest to take up the
draft.  There's always more people on the list who make comments, than
come to meetings.  And I note this was before the scandal erupted. Now,
the scandal seems to have created an obligation to review the draft, and
it _still_ isn't a working group item. I find that objectionable.

The IESG can't remove the taint of scandal by itself. (hence the
assurance the TLS group would review the draft; wasn't much of an
assurance, it turns out).

I was also wondering about the disproportion to the fact that the TLS WG
has taken up a slew of authentication drafts, but no authorization
drafts. One seems complementary to the other.  There are some
implementations of Housley, people are interested in writing code.  Why
aren't people on the WG interested in authorization?  This seems odd to
me. Some clue here would be helpful.

		--Dean

---

From: "Andres Marin" <[email-masked]>
Date: Tue, 12 Jun 2007 14:00:00 +0200

> doesn't seem critical), that would be very useful information.

We have been working in authorization extensions for TLS since 2004 at
the University Carlos III de Madrid. When we noticed the drafts of Mr.
Housley and Mr. Brown, we contacted them since the discussion in the
TLS group by then was over. We sent them our comments plus the paper
we were writing to a journal, and also a toolkit for AC
attributes based on openssl. The API is available for download at
http://www.it.uc3m.es/dds/swRelease/pmi/pmi.xml.
We exchanged some emails since our intention was to collaborate in
writing a better draft for authorization, but in the end this did not
happen.

Our main comments to draft-housley-tls-authz-extns-07 were:

- The double handshake to ensure auth data is exchanged over a secure
channel can be unacceptable for some applications, or at least it
could be improved. We are unsure if there is another motivation for
this, perhaps the reduced complexity to implement new servers... We
think that after the extension, a new authorization protocol message
should be used, to avoid double handshake and also to prevent
man-in-the-middle attacks and preserve privacy of authorization
information.
- In the case of SAML, the extension does not allow a server to
indicate the client if a given issuer would be accepted as a valid
SoA. It does not either allow the client to indicate the SAML protocol
binding or the assertion consumer endpoint.

We submitted our work to IEEE Security & Privacy Conference 2007,
but they found it more appropriate for IETF discussion. You can find
it here: http://karajan.it.uc3m.es:9673/pervasive/tls-auth/TLSExtv4.pdf
user:draft passwd:extn-07

We were considering sending a draft with a proposal for authorization
extension in TLS. But after this discussion, and specially some
reasonable complaints about the increasing complexity in client and
server hello messages, we think that may be it is better to specify
new layers for dealing with such extensions. The idea is not to
include further negotiations in TLS handshake (in our case
authorization, but may be others), and just indicate in the hello
messages the layer ids to deal with such negotiation, where the new
layers will be clients of the Record Layer.

-- Daniel Díaz Sánchez & Andres Marin Lopez
Universidad Carlos III de Madrid
http://www.it.uc3m.es/pervasive