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: SubjectConfirmation descriptions


Title: [security-services] New Issue: SubjectConfirmation descriptions

I think the descriptions of the subject confirmation method are inadequate.

1. There should be enough info to allow interoperation without prearrangement.
2. Ideally we should give implementors some guidance on the intented use of each, in particular, when to use one vs. another.

General Comments:

There is no reference for SHA1. The reference is RFC3174. D. Eastlake, 3rd, P. Jones US Secure Hash Algorithm 1 (SHA1) September 2001 http://www.ietf.org/rfc/rfc3174.txt ALso decide if it is SHA-1 or SHA1 and stick to it.

All binary quantities should be represented the same way. Suggest base 64

Specific:

SAML Artifact - if this is specifically the SAML artifact and not just any random binary nonce, this should reference the bindings doc, Browser Artifact Profile, section on Artifact format (would be easier if doc had numbered sections) Also state if must be typecode 1 or can be any typecode. Also should say: This Method is used when a web browser is issued an artifact by the asserting party and later presents it to the relying party.

SAML Artifact (SHA1) - ditto the above. Plus, why do we need both of these? Hashing is good because you cannot derive Artifact from looking at assertion. Why not use it all the time? On the other hand, the Profile specifies one-time use for the artifact, so I don't really see the threat. Either way I think we should drop one of these.

Holder of Key - What kind of key? It says "Any Cryptographic Key" but then indicates it is a Public Key. Should include a reference to [XMLSig]. Do we really want to support all the KeyInfo sub-elements, or just KeyValue? Looks to me like a lot of these, like KeyName, X509Data, PGPData, SPKIData and MgmtData, will just cause trouble and bloat implementations.

Sender Vouches - This one still puzzles me and I know it will puzzle anybody outside the TC. Can't we incorporate some of the discussion from the list about what this is intended for?

Password (Pass-Through) - What is the significance of "pass-through"? I hope somebody isn't trying to do a Credentials Assertion by the back door. Is this intended to be a long term password, or can it be some kind of artifact-like nonce? Does it have to be the password used for authentication if this is an authentication assertion? If it is, what is the value of the Authentication Assertion? Whay would anyone want to send this unhashed if this is being used as a confirmation method or is it being overloaded as an encrypted attributed for  proxy login purposes?

Password (One-Way-Function SHA-1) - Why is this one "One-Way-Function" and the others just "SHA-1"? I gather this is not intended to cover the case where the hashed password is stored in the repository and the AP does not know the real password. I would drop the previosu one in favor of this one.

Kerberos - Specify Kerberos 5. What kind of ticket? A ticket granting ticket makes no sense, so I assume this must be a service ticket targeted to the relying party. Should say so. Also specify base 64. Does username and realm in ticket have to match Security Domain and Name in NameIdentifier? Or should the Security Domain be missing (or blank) and the Name contain realm@username? Implementors will have to consider ticket lifetime as it could be shorter than Assertion validity. Also not this doesn't make that much sense in an Authentication Assertion.

SSL/TLS Certificate Based Client Authentication - Does it have to be different from Holder of Key? Will we need another for SMIME, etc?

Object Authenticator (SHA-1) - How can an XML document be a Subject? I thought a subject refered to a system entity. Don't see how this would work in practice. Does the AP do the hashing? Does the RP do the hashing? If neither, don't see it provides any more protection than a simple random nonce.

PKCS#7 - Thought this would be redundant with ds:KeyInfo, but looking at [XMLSig] apparently not. Why does this have to be signed? Isn't the whole assertion signed? Isn't signing optional? The description is nice and long, but doesn't a lot of it apply to other Confirmation Methods as well? What part is unique to this one?

Cryptographic Message Syntax - ditto PKCS #7, except this time there is no explaination of how it is used for confirmation.

XML Digital Signature - ditto on being signed. Also no description of how confirmation is accomplished. How is its intended use different from say, Holder of Key?

As noted elsewhere, the "Bearer" method dropped in the bit bucket.

Hal



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


Powered by eList eXpress LLC