Re: AC Scenarios - PUSH model

[Steve Hanna <steve.hanna@xxxxxxx>]

Anders Rundgren wrote:
> I would like to particularly discuss TLS PUSH as it *theoretically*
> at least could be of major interest in e-business.
> 
> > C) TLS push
> >
> >    Client sends ACs to server (probably requires modifications to the
> >    TLS handshake). Server uses ACs to make authorization decisions.
> 
> This is the $1000 000 question: Will this really happen?  Will you
> (SUN) start to push this in the TLS-group?  Because if you (and the
> others) don't, ACs will be left in a pretty miserable shape.  Sort of
> "nowhere to go" -:(

I have no specific plans to push (or pull ;-) any particular model for
using ACs at this time. In fact, I noted my concerns with the TLS push
model at the end of my note. Why do you think that if TLS push is not
used, ACs will be in "pretty miserable shape"? What about the other
scenarios?

> >    Client authentication using PKCs will probably be most common here,
> >    but the client may also authenticate using a username and password
> >    (after authenticating the server), one-time password, Kerberos, or
> >    another technique.
> 
> Modifying TLS to carry ACs but not requiring a (cryptograhically linked) PKC is probably
> a bad idea. If you really have been able to get an AC (on your hard-disk, in a smart-card or
> in your mobile phone), you should be equipped with PKCs as well.

I also am not thrilled with pushing ACs that are not linked to a PKC (or
at least a PK). I was simply trying to enumerate the possible scenarios
to determine the implications for holder formats.

> A question that comes to my mind is whether this scheme offers *any* advantages over
> the scheme suggested by Bob J in terms of distribution of certificates? Bob's scheme
> does *not* require changes in TLS.  Although I am personally not very thrilled [working
> on a competing solution :-)], by the following idea, multiple client PKCs (containing
> different AC-like data and issued by possible different issuers) could share a common key-pair.
> By doing that a client can securely download additional "PKC-AC"s when needed from an
> existing trusted PKC.

Putting attributes in a PKC mixes short-lived bindings with long-lived
ones, reducing the likely validity of the PKC. And many organizations
want to manage authorization separately from authentication. I do not
mean that attributes should NEVER be put in PKCs, but there are
certainly some strong arguments against doing so. And there is little
benefit in the pull scenarios.

-Steve