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

["Andres Marin" <amarin at it.uc3m.es>]

On 6/11/07, Simon Josefsson <simon at josefsson.org> wrote:
> 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.

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

> /Simon
>
> _______________________________________________
> TLS mailing list
> TLS at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls