[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Public Comment
Comment from: trscavo@gmail.com Name: Tom Scavo Title: Research Programmer Organization: National Center for Supercomputing Applications Regarding Specification: SAML Attribute Sharing Profile for X.509 Authentication-Based Systems Document identifier: sstc-saml-x509-authn-attrib-profile-cd-02 My comments re previous versions of this document: http://lists.oasis-open.org/archives/security-services-comment/200503/msg00000.html http://lists.oasis-open.org/archives/security-services-comment/200503/msg00001.html Errata: [line 2] s/SAML/SAML V2.0/ [line 19] s/SAML/SAML V2.0/ [line 36] s/SAML/SAML V2.0/ [line 61] s/SAML/SAML V2.0/ [line 77] Define namespace prefixes in section 1.1 [line 78] s/SAML/SAML V2.0/ [line 85] s^Encrypted^Encrypted/Signed^ [line 89] s/SAML/SAML:2.0/ [line 90] s/SAML/SAML:2.0/ [line 97] s/web/secured/ [line 98] s/through the presentation of/by presenting/ [line 99] s/and not/not/ [line 99] s/by the demonstration of/by demonstrating/ [line 103] s/DistinguishedName/Distinguished Name/ [line 111] In the diagram on page 5: s/TLS Authentication and Initial Request/Initial Request and X.509 Authentication/ [line 111] In the diagram on page 5, add this step: "2.5 Check Policy" [line 113] s/TLS Authentication and Initial Request/Initial Request and X.509 Authentication/ [line 115] s/requests/requires/ [line 120] s/SAML/SAML V2.0/ [line 121] s/Binding, using the/Binding. The/ [line 122] s/within/is used to construct/ [line 144] s/send an/send a SAML V2.0/ [line 147] s/identity using this mode/identity provider/ [line 147] s/In addition/For instance/ [line 152] s/it will/the identity provider SHOULD/ [line 157] s/mdext:AttributeRequesterDescriptorType/query:AttributeQueryDescriptorType/ [line 161] s/Section/section/ [line 161] Append to this line: "unless otherwise specified below" [lines 164--166] Remove the extra indentation. [line 164] s/with the value of/whose value is/ [line 166] Remove the period at the end of the line [line 169] s/Section/section/ [line 176] s/It/The <Assertion>/ [line 176] s/reflects/conveys/ [line 183] s/In this mode/In this mode, as in basic mode/ [line 183] s/send an/send a SAML V2.0/ [line 184] s^It^Encrypted/Signed Mode^ [line 192] s/it will/the identity provider SHOULD/ [line 198] s/mdext:AttributeRequesterDescriptorType/query:AttributeQueryDescriptorType/ [line 203] s/Section/section/ [line 204] s/SAMLSecure/SSL3/ [line 204] s/RFC3280/RFC2246/ [line 208] s/must/MUST/ [line 209] s/defined in/defined in the W3C XML Encryption specification/ [line 211] Replace the period at the end of the X509SubjectName format with a line break. [line 211] s/Section/section/ [line 213] s/It/The <AttributeQuery> element/ [line 215] s/assertions and protocols/Assertions and Protocols/ [lines 216--217] Join these lines. [line 217] s^this mode^Encrypted/Signed Mode^ [line 217] s/<EncryptedID>/<EncryptedID> element/ [line 220] Delete the phrase "to conform to the Encrypted/Signed Mode". [line 221] Delete the phrase "using this method". [line 221] s/service provider then places/service provider places/ [line 224] s/Service Provider/service provider/ [line 226] Delete the phrase "using this method". [line 226] s/service provider then places/service provider places/ [line 227] s/element and the/element. In this case, however,/ [line 230] s/assertions and protocols/Assertions and Protocols/ [lines 234--235] s/A [FIPS 140-2] validated digital signing algorithm/A signing algorithm satisfying FIPS 140-2 Security Requirements [FIPS 140-2]/ [line 238] s/Section/section/ [line 239] s/SAMLSecure/SSL3/ [line 239] s/RFC3280/RFC2246/ [line 257] s/assertions and protocols/Assertions and Protocols/ [lines 258--259] Join these lines. [line 259] s^this mode^Encrypted/Signed Mode^ [lines 261--262] Delete the phrase "to conform to the Encrypted/Signed Mode" [line 266] s/Service Provider/identity provider/ [lines 266--267] s/used in the <AttributeQuery> for encrypting/used by the service provider to encrypt/ [lines 267--268] Delete the phrase "containing the Subject DN in order to encrypt the returned <Assertion>" [line 268] s/the key/a key/ [lines 271--272] s/Service Provider/identity provider/ [lines 274--275] s/A [FIPS 140-2] validated encryption algorithm/An encryption algorithm satisfying FIPS 140-2 Security Requirements [FIPS 140-2]/ [line 277] s/assertions and protocols/Assertions and Protocols/ [lines 281--282] s/A [FIPS 140-2] validated digital signing algorithm/A signing algorithm satisfying FIPS 140-2 Security Requirements [FIPS 140-2]/ [line 290] s/uses/presents/ [line 291] Insert a comma after "i.e." [line 293] s/SAML/SAML V2.0/ [line 293] Change the font of element <AttributeQuery>. [line 294] s/out-of-scope/out of scope/ [line 319] Insert this missing reference: [RFC2246] T. Dierks and C. Allen. The TLS Protocol Version 1.0. IETF RFC 2246, January 1999. See http://www.ietf.org/rfc/rfc2246.txt [line 320] This reference should read: [RFC3280] R. Housley et al. Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile. IETF RFC 3280, April 2002. See http://www.ietf.org/rfc/rfc3280.txt [line 322] s/OASIS/OASIS Standard/ [line 324] Remove the comma after "et al." [line 328] s/Assertions and Protocol/Profiles/ [line 329] s/(SAML V2.0)/(SAML) V2.0/ [line 329] s/OASIS/OASIS Standard/ [lines 329--330] s/sstc-saml-profiles-2.0-os/saml-profiles-2.0-os/ [line 335] s/S. Cantor/T. Scavo and S. Cantor/ [line 335] s/SAML Metadata Extension for a Standalone Attribute Requester/SAML Metadata Extension for Query Requesters/ [line 336] s/March 2005/March 2006/ [line 336] s/sstc-saml-metadata-2.0-cd-01/sstc-saml-metadata-ext-query-cd-01/ [line 337] The reference URL should be: http://www.oasis-open.org/committees/download.php/18052/sstc-saml-metadata-ext-query-cd-01.pdf [lines 338--341] Set this reference in roman text, not boldfaced text. [line 339] s/OASIS SSTC/OASIS Standard/ [lines 340--341] The reference URL should be: http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf [lines 342--343] This reference should read: [SSL3] A. Freier et al. The SSL Protocol Version 3.0. IETF Internet-Draft, November 1996. See http://wp.netscape.com/eng/ssl3/draft302.txt [line 346] Remove the extra indentation. [line 346] Remove the comma after "et al." [line 347] Insert "See" before the reference URL. Comments/Suggestions: [section 2] The normative subsection 2.1 should not be in the same parent section as the non-normative subsection 2.2. Use the word "non-normative" somewhere in subsection 2.2. [line 89] Move this URI into section 3. [line 90] Move this URI into section 4. [section 2.2.1] Define the terms "identity provider" (SAML attribute authority) and "service provider" (SAML attribute requester) as used in this profile. The SP, in particular, is not a typical SAML service provider since it performs X.509 authentication instead of consuming a SAML authentication assertion. [section 2.2.2] The use case in subsection 2.2.2 presupposes transport-level security (i.e., TLS). It would be better not to mention TLS at all in this subsection. [lines 116--117] Delete the sentence "The service provider authenticates to the principal at the same time (that is, TLS or SSL mutual authentication is performed)" since the SP is not required to authenticate to the principal. Indeed, this profile does not constrain this step. [lines 117--118] Delete the sentence "Subject confirmation is performed by the service provider as part of the TLS authentication" since this sentence adds little, if anything, to the use case. [lines 123--124] Delete the phrase "and a format with the value of urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" since this normative text is spelled out in section 3. [lines 127--129] Move these lines to section 6. Although the Subject DN may be used for this purpose, this practice may detract from interoperability and is therefore discouraged. Likewise the Issuer DN may provide clues about the principal's preferred IdP, but this is not usually the case since SAML authorities do not typically issue X.509 credentials. The issue of "IdP Discovery" should be discussed more fully in section 6. [lines 133--135] Move these lines to section 5. The reason given for message-level encryption and signing is inadequate since confidentiality and integrity are provided at the transport level. In fact, message-level encryption and signing is particularly useful in multi-hop scenarios, which should be mentioned. [line 151] The phrase "based on authentication of the requester" is not applicable since client authentication is not required. [section 3.1.1] What about the NameQualifier attribute? It should be set to the Issuer DN of the X.509 certificate. This will practically guarantee global uniqueness of the name identifier. [section 3.2.1] What does the IdP do if it does not support this profile? In this case, recommend the use of status code urn:oasis:names:tc:SAML:2.0:status:UnknownAttrProfile. [section 3.2.1] What does the IdP do if it does not recognize the NameID or otherwise is unable to map the NameID to a local principal name? In this case, recommend the use of status code urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal. [section 4] Various SSL/TLS requirements are spread out over section 4 (line 188, lines 194--195, lines 204--205). Can these requirements be consolidated? [section 4] The requirement that the <AttributeQuery> element MUST be signed is stated three times (lines 187--188, line 213, and lines 233--234). Eliminate this redundancy. [section 4] Note that Encrypted/Signed Mode requires the IdP to authenticate itself three times (SSL/TLS server authentication, message signing, and by decrypting the NameID in the query). I agree this is necessary in this case, but an explanation would be helpful. [lines 194--195] These lines do not fit with the rest of the paragraph. [lines 219--228] Since the normative text on lines 219--223 is a MUST, the normative text used in the following paragraph on lines 224--228 is contradictory. Instead, list two alternative options, one of which MUST be used. [section 4.2.1] Does the name identifier in the response need to be encrypted? I suppose you want that, but you need to be explicit since that is not required by [SAMLCore]. [sections 4.1.2 and 4.2.2] Combine these sections. [lines 261--275] Since the normative text on lines 261--265 is a MUST, the normative text used in the following paragraphs on lines 266--269 and lines 270--275 are contradictory. Instead, list three alternative options, one of which MUST be used. [sections 4.1.3 and 4.2.3] Combine these sections. [lines 292--294] Delete the phrase "by obtaining the X.509 subject name from the end-user certificate and issuing a SAML <AttributeQuery> for that subject to the appropriate asserting party". [lines 298-300] In fact, the relevant security bits to be observed are in section 3.1.2 of [SAMLBind]. This should be reinforced in section 5. [section 6] Normative language should not be used in section 6 (which itself is non-normative). [section 6.1] The last sentence in section 6.1 addresses a privacy issue, whereas the rest of the subsection addresses security issues. Moreover, the first two sentences of section 6.1 have nothing to do with "Identity Provider Policy." As a result, the subsection does not read well and consequently these two issues deserve their own subsections. [section 6.2] The last sentence in section 6.2 addresses a privacy issue, and so it should be combined with the last sentence in section 6.1. [sections 5--6] If you change the title of section 5 to "Security and Privacy Considerations," most of section 6 can be moved to section 5. [section 7] Reference [SSL3] copied from [RFC2246] is incorrect at the source. For one thing, the lead author's name is spelled incorrectly. The correct reference is given in the Errata section. [general] The document sometimes refers to "encrypted mode" while other times it refers to "encrypted/signed mode." Be consistent throughout. [general] Encrypted mode provides message-level security. Basic mode, on the other hand, provides transport-level security (primarily). That's an important distinction the reader can use to determine which mode is appropriate for their particular use case. ---------------------- Tom Scavo NCSA/University of Illinois
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]