RE: [security-services] X509 authn based attribute protocol profile

["Scott Cantor" <cantor.2@osu.edu>]

> *	There doesn't appear to be any tying of the DN 
> presented by the SP to an actual authentication event at the 
> SP (e.g. the SP can remember the DN for days, weeks, years 
> and reuse it whenever it wants).    In fact, the SP could 
> just make up a DN and try it to see if it works or the SP 
> could have gotten the DN from another SP.  Either we should 
> solve this problem or we should say that this has nothing to 
> do with authentication and just say it is DN based attribute 
> lookup (we don't care how the DN got to the SP as far as I 
> can tell in the protocols).

I made roughly the same argument originally, but couched it more in terms of
restricting the profile to address only the attribute exchange and not the
authentication process. The response, IIRC, was that without defining the
specific use case (TLS client authn via HTTP), the overall use case wouldn't
be implemented by products claiming to support the profile with any
consistency and the customer wouldn't get their RFP shortcut.

I agree with your position, but I don't think it's an easily solved problem
to tie them together. Maybe the only compromise is to simply note the
constraint that while the use case modeled may extend beyond the attribute
query, the security mechanisms and trust models involved don't.

-- Scott