Draft: draft-ietf-sip-saml-02
Reviewer: Richard Barnes
Review Date: 18 Jun 07
Security / Privacy Concerns:
------------------------------------------------------------------------
1. It's never made clear what entity is the Subject of the conveyed
assertions. This could be a critical distinction, e.g., if one party
assumes that it's the UAC being discussed, and the other the user of the
UAC.
2. Section 9 needs a discussion the nature of the assurances provided by
SAML assertions. In general, in order for it to be verifiable that the
SAML assertion was issued by the Authentication Service, there must be
proof that the holder of the private key used to create the
Identity-Info header. There are several ways to do this:
2.a. The SAML assertion is signed with the appropriate private key
2.b. An unsigned SAML assertion is provided over HTTPS by a server that
authenticates with the same certificate
2.c. The Identity-Info is integrity-protected from the point where it is
added by the Authentication Service until it reaches the UAS.
3. The list of threats and countermeasures in Section 9 is incomplete.
For instance:
3.a. There's no discussion of threats of attacks by elements of the SIP
signaling path (e.g., manipulating the URI in the Identity-Info header)
3.b. The anti-replay mechanism should reference the expiry elements
built into the assertion (e.g., the NotOnOrAfter attribute)
4. The document isn't clear on whether or not the assertions MUST be
signed by the issuer. Section 6.1.5, step 3 seems to imply that the
assertion will be signed, but Section 9.3 seems to assume that this
isn't necessarily the case. IMHO, it should be that the assertion MUST
be signed by the same key used to generate the identity digest. But
even if this isn't the case, this point should be clarified.
5. No mention is made of the possible sensitivity of the contents of
SAML assertions. It's possible that these assertions could contain
sensitive information about the Subject, such as statements about what
identities the subject holds. There should be some discussion about
what measures should be taken in this case, e.g., the use of HTTPS and
authentication of dereferencing clients.
General Comments:
------------------------------------------------------------------------
1. Conveying SAML assertions via a URI in the Identity-Info header
contradicts Section 9 of RFC 4474, which says that the resource
indicated MUST be of type "application/pkix-cert". ISTM there are at
least a couple of ways to fix this:
1.a. Normatively update RFC 4474 to allow the resource to be of either type
1.b. Normatively update RFC 4474 to allow for a "multipart/mixed" with
one part of each type
1.c. Add a separate header to carry the SAML assertion
In the interest of backward-compatibility, I don't think you can get rid
of application/pkix-cert altogether.
2. The subdivisions under sections 6 and 7 seem unnecessary. Section
6.1.X should be Section 6.X (or maybe 6.(X+1)), and likewise for section 7.
Localized Comments and Nits:
------------------------------------------------------------------------
Section 2:
I would switch the order of the definitiosn of "profile attribute(s)"
and "user profile, subject profile".
Section 3, paragraph starting "Thus one can employ...":
Change "to make and encode statements" to "to encode statements".
Section 6.1.2, paragraph starting "Although this...":
Change "this profile is overview is" to "this profile overview is"
Figure 2:
In the INVITE messages, the AoR in the From: header should be
"sip:[EMAIL PROTECTED]"
Section 6.1.2, Step 3:
The AS is supposed to insert "attributes required by Bob's domain". How
is it supposed to know which attributes these are? This is answered by
the following paragraph, which should be moved up to here.
Section 6.1.2, Step 3:
The AS constructs a "HTTP-based SAML URI reference" -- shouldn't this be
a reference according to the binding defined in this document, instead
of the original (SAMLv2) reference standard?
Section 6.1.2, Step 5, second paragraph:
"the AS continues" should be "the UAS continues"
Section 6.1.3.3, third paragraph:
This paragraph gives the option of HTTPS or HTTP, but doesn't specify
that one of the two MUST be used. Suggested text: "The AS MUST
construct either an HTTP or HTTPS URI per Section "3.7.5.1 URI Syntax"
of [OASIS.saml-bindings-2.0-os]. It is RECOMMENDED that the AS
construct an HTTPS URI."
Section 6.1.3.3, fourth paragraph:
This is not technically correct; the URI should be the absoluteURI
portion of the Identity-Info header value.
Section 6.1.4:
Through out this section, situations with exceptions are presented as
"SHOULD ... MAY ...". As I read it, this creates a situation without a
mandatory default behavior; I would prefer if these were worded as
MUSTs, with MAYs allowed under specified circumstances.
Section 6.1.4.1.3:
The SHOULDs in this section should be should be MUSTs.
Section 6.1.4.1.4, second paragraph:
This needs to say that the attribute-value pairs MUST pertain to the
subject of the assertion (a concept which needs to be tied to a SIP
entity elsewhere in the document). This may be the entity identified in
the From header, or another identified entity.
Section 6.1.5, Step 3:
Section 5.4 of the indicated reference doesn't say anything about how
signatures are verified. Instead, this should reference Section 3.2 of
the XMLdsig document referenced. Also is this TODO resolved?
Section 6.1.5, Step 5:
Specify how this verification is done, e.g., by verifying that the
signed-identity-digest and the signature on the SAML assertion are both
verifiable with the key in the cert in the assertion.
Section 6.1.5, Step 7:
The relevant field in the X.509 certificate are Subject and Subject
Alternative Name (not Issuer and Issuer Alternative Name). The Issuer
of the assertion is the Subject of the certificate.
Section 7:
This binding doesn't really have anything to do with SIP. Could we just
exclude SIP from the name? Maybe this could be the IETF standard URI
binding of SAML.
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
