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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: [security-services] New Issue: Should Queries contain a full Subj ect?

Title: [security-services] New Issue: Should Queries contain a full Subject?

Although I am reluctant to raise a new issue at this point I feel I cannot let this one go by.

Curently, all <Query> elements contain a Subject element. (Actually, SubjectQuery but I am not proposing we change that.)

Obviously we need <NameIdentifier> but what about <SubjectConfirmation>? My recollection is that the idea was an SPKI-like concept of using a Public Key as a pseudonym. Very well, but I don't think the other confirmation methods make much sense and some of them are confusing and dangerous.

First, the confusion aspect. Many people expect to see a proxy login capability and therefore, in spite of the text in sections 1.3.1 and 3.3.3 expect that by putting in a password, they can request that the authority verify the password and issue a new Authentication Assertion. My developers made this mistake and in fact the article forwarded by Edwin DeSousa via Eve and linked to by the SSTC web page makes the same mistake.


However, if you interpret this Query according to the spec it is even worse! Since the server is required to only provide Assertions with matching subject, it is possible, for example, to make a series of Attribute Queries, about a known subject and provide guessed password values, until you get a match. Or better still, leave out the NameIdentifier and ask for the attributes of any user with the password of X. Good values for X include, the name of the company and the words "default" and "password". This will get at least one hit in any organization of 100 or more people.

As Prateek pointed out this attack applies to any method data which is a secret.

Other methods are merely useless. Do you really want to specify a specific Kerberos ticket, with or without a NameIdentifier?

I see three likely solutions. (Clearly there are many alternatives.)

1. Use NameIdentifier instead of Subject in the SubjectQuery. The argument is that other methods of pseudonymity are available.

change line 1271 and 2314 to: <element ref="saml:NameIdentifier"/>

2. Use either or both of NameIdentifier and HolderofKey. This permits the one identified use, but prevents the confusing and dangerous ones.

change line 1271 and 2314 to:
                                <element ref="saml:NameIdentifier"/>
                                <element ref="saml:HolderofKey" minOccurs="0"/>
                        <element ref="saml:HolderofKey"/>

Note that either choice 1 or 2 reduces code required in a SAML Responder quite a bit.

3. Leave Subject in place and describe the threat of responding to methods like password that contain secrets.

Explicitly allow servers to respond to any query with an error like "bogus request".

Add a discussion of the threat to the security considerations document.


Regardless of which of these is chosen, make the following change:

After the end of the sentence on line 1279, insert a new paragraph:

Note: The AuthenticationQuery MAY NOT be used as a request for a new authentication using credentials provided in the request. The AuthenticationQuery is a request for statements about authentication acts which have occured in a previous interaction between the indicated principal and the Authentication Authority.



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

Powered by eList eXpress LLC