OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [security-services-comment] Specifying Issuer (vs. Subject)


Title: RE: [security-services-comment] Specifying Issuer (vs. Subject)

> > If an AP wishes to take some of the
> > information from an X.509 certificate and use it to construct an
> Attribute
> > Assertion, this is certainly legal, although not clearly useful.
>
> One use is to simplify the relying application, by providing it with a
> uniform assertion, derived from multiple kinds of credentials - X.509
> certificates, attribute certificates, database lookups, ...

Agreed. SAML allows you to do this as it currently stands.

> I am not sure I understand your use case, but you appear to be trying
to
> use SAML to establish a trust relationship.

>Definitely not. I'm trying to use SAML as a format for an a security
>assertion. Part of this assertion is information about the issuer. This
>in turn may be used by a relying application to make its trust decisions
>(and in particular to request certificates for the issuer).

I guess we are miscommunicating on a basic level here. SAML assumes that, from a Relying Party's perspective, there are a very large number of system entities that make requests and that there are a quite small number of Asserting Parties (issuers) which it has decided to trust for reasons and by means that are out of scope of SAML. SAML provides the means by which Asserting Parties can publish information about the system entities in question.

Under this model, the information about an issuer is provided so the RP can confirm that the AP is one of those it has decided to trust. The mechanism is not intended to allow the AP to publish information about itself. The reasoning is that if the AP is not trusted, there is no reason to believe anything it asserts. On the other hand if a trust relationship has already been established by other means, those means can be used to obtain any needed information.

I guess if you wanted to set up new APs, you could do this by making them the subject of a SAML Attribute Assertion. This assumes that there is a meta-AP which can vouch for APs. I don't see any particular difficulty in doing this, but it was not a goal of SAML. There are perfectly good existing infrastructures, such as PKIX which can do this and SAML is not intended to replace them.

> This seems like a rather undesirable feature. Doesn't accepting a
trusted
> key from an unknown party on the fly pretty much negate the value of
> cryptographic authentication?

Initially it may appear so, but in many cases, there is value in
authenticating first, even before knowing that the other party is valid,
and only then gathering the necessary info to determine validity.

Do you mean like a pure Diffie-Hellman key exchange, followed by mutual authentication using some kind of shared secrets? This is certainly possible, but I don't see the advantages.

One major disadvantage of schemes like this is denial of service. An attacker who is not a legitimate user can make you do a lot of work.

> In any event, it seems to me that all the information you seek would
be
> available to the party establishing the original SSL connection, in
the
> form of the certificate chain used to authenticate the other party.

Yes, the info is in the certificate chain, but of course it doesn't make
sense to use both this and SAML.

Why not? You were the one who proposed SSL as a use case. SSL REQUIRES that the certificates be exchanged in band and verified. Therefore the RP must be capable of processing this data.

Hal



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC