W3C home > Mailing lists > Public > ietf-tls@w3.org > July to September 1996

Re: Password Deployment Issues and Attribute Certificates

From: Jason S. Smith <jason@mitre.org>
Date: Thu, 01 Aug 1996 08:53:30 -0400
Message-Id: <3200A8CA.6FC8@mitre.org>
To: Bennet Yee <bsy@cs.ucsd.edu>
Cc: ietf-tls@w3.org, Eric Murray <ericm@lne.com>
Bennet Yee wrote:
> 
> 2.      Authorization via Attribute Certificates
> 
> While I believe attribute certificates are wonderful and useful, I
> believe that protocols to access them should be layered on top of TLS.
> By crossing the layer boundary, we only further confound
> authentication and authorization with no real gain (in conceptual
> clarity, in efficiency, or in any other metric that I can think of).
> 

An attribute certificate will typically be tied to the authentication
certificate via issuer and serial number.  An attribute certificate
without an authentication certificate has little value.  If we are going
to provide authentication certs to applications for audit, access
control, etc, then we should be prepared to handle the luggage (i.e.,
attribute certs) that accompanies auth certs.

> Anyway, from a security viewpoint, authentication and authorization
> are very different ideas.  

Yes, but both are really relying on the application layer.  We can not
authenticate a user if their authentication cert chain does not end in
some known root.  TLS, SSL, etc, do not define these trusted roots,
these are handled by the applications themselves.  CRLs are also a large
part of authentication, which are also currently the responsibility of
the application.  SSL provides negotiations, integrity, and encryption. 
It also provides a standard means for challenge response, and can verify
authentication to some degree (that the response is associated the
certificate presented), but the application is ultimately responsible
for verifying authentication data.

> There is certainly no reason why the
> attribute certificate request must occur as part of the initial
> handshake: with a ``keepalive'' connection which handles multiple HTTP
> requests, different authorizations may be required for the different
> HTTP requests, and tying the attribute certificate request/reply to
> the initial handshake is wrong.  The proof of -authorization- for the
> operations being performed must be requested when it's clear what
> those operations are, not before in a willy-nilly fashion.

Different http requests may also require different authentications,
either do to key strength, algorithm, or certificate chain root. 
Keepalive is only useful when the security context is the same for all
bundled HTTP requests.

Most of the traffic I have seen on this list appears to be hammering out
the same negotiation issues that have debated in other working groups,
so I again ask why we don't choose to use ISAKMP as a negotiation
mechanism?  I have yet to hear any reasons why not to use ISAKMP, and
have only heard reasons for using it.

Jason Smith
The MITRE Corporation
Received on Thursday, 1 August 1996 08:56:56 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:34:50 EDT