Subject: [Sip] SIP SAML Review by Richard Barnes

From: Richard Barnes <[email-masked]>
Date: Wed, 20 Jun 2007 23:44:26 -0400

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-masked]"

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jeff Hodges <[email-masked]>
Date: Fri, 29 Jun 2007 14:40:48 -0700

> of application/pkix-cert altogether.

thanks, yes this is definitely an issue. We'd noticied it soon after RFC4474's 
publication. There was a 3-message thread at the end of Oct-2006 discussing it. 
Hannes' final message..

   Re: [Sip] Re: wrt RFC4474 'absoluteURI' in Identity-Info header field and
   SIP-SAML implications
   http://www1.ietf.org/mail-archive/web/sip/current/msg17101.html

..summarizes it well, and proposes essentially Richard's proposed 1.c. solution 
(note that the ostensible new header would convey a URI rather than a SAML 
assertion by-value (conveyance of complex objects by-value in SIP header fields 
being a higher-level (contentious) issue).

Also note that this is issue12 in the sip-saml tracker..

   http://www.tschofenig.priv.at:8080/saml-sip/issue12

In his message of Tue, 31 Oct 2006 03:54:02 -0400, Hannes was thinking that the 
equivalent of option 1.c above would be the likely course of action.

However, option 1.{a,b} would be possible if draft-ietf-sip-saml-xx were to 
appropriately normatively update RFC4474 wrt the specific language of the 
second para of page 15 (in RFC4474).

What do folks think we should do here?

thanks,

=JeffH