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

["Randall Rick" <randall_rick@bah.com>]

All,

I am planning to discuss Conor's comments with my customer that is using
the profile early next week, to see what we can do with them.

Have a good weekend.


V/R,

 ~ Rick

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Thursday, June 02, 2005 8:07 PM
To: 'Conor P. Cahill'; 'SAML'
Subject: RE: [security-services] X509 authn based attribute protocol
profile

> *	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