Subject: Re: [Sip] SIP SAML Review by Richard Barnes - security/privacy considerations

From: Jeff Hodges <[email-masked]>
Date: Fri, 06 Jul 2007 17:26:02 -0700

Richard Barnes wrote:
 >
 > 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.

section "6.1.4.1.2.  Element: <Subject>" stipulates..

    The <Subject> element SHOULD contain both a <NameID> element and a
    <SubjectConfirmation> element.

    The value of the <NameID> element MUST be the same as the Address of
    Record (AoR) value used in computing the "signed-identity-digest"
    which forms the value of the Identity header.  See Section 9 of
    [RFC4474].

So, whatever is (currently) being stuffed into AoRs also goes into the 
Subject/NameID element.

Does that answer this?

 > 2. Section 9 needs a discussion the nature of the assurances provided by
 > SAML assertions.

Yes, though more specifically, the nature of the assurances provided by a SAML 
assertion constructed, and referenced by a SIP request, as specified in this spec.

 > 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.

Agreed, though this is in the spec.

 >There are several ways to do this:
 > 2.a. The SAML assertion is signed with the appropriate private key

This is specified in section "6.1.4.  Assertion Profile Description/Overall 
SAML assertion profile requirements:"...

       The SAML assertion MUST be signed by the same key as used to sign
       the contents of the Identity header field.  Signing of SAML
       assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os].

 > 2.c. The Identity-Info is integrity-protected from the point where it is
 > added by the Authentication Service until it reaches the UAS.

This is a basic feature of rfc4474.

 > 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)

yes, ok.

 > 4. The document isn't clear on whether or not the assertions MUST be
 > signed by the issuer.

This is specified in section "6.1.4.  Assertion Profile Description/Overall 
SAML assertion profile requirements:"...

       The SAML assertion MUST be signed by the same key as used to sign
       the contents of the Identity header field.  Signing of SAML
       assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os].

..tho perhaps we should clarify that the wielder of this key is "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.

hm, I don't see that. RFC4474 goes into gory detail wrt the signing of the 
identity headers and I didn't want to replicate it here. Plus as noted above, 
the -sip-saml-02 says assn MUST be signed (with same key as signed Identity 
header field).

 > IMHO, it should be that the assertion MUST
 > be signed by the same key used to generate the identity digest.

agreed ;)

 > 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.

ah, indeed. good catch.

 > 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.

ok.

 > Section 6.1.5, Step 3:
 > Section 5.4 of the indicated reference doesn't say anything about how
 > signatures are verified.

well, that's not exactly true. There's info therein about certain first-order 
properties assns must have in order to verify correctly and such, so it still 
needs to be referenced imho. But yes, it doesn't provide a step-by-step guide 
for doing so.

 > Instead, this should reference Section 3.2 of
 > the XMLdsig document referenced.

will be more explicit about the references into XMLdsig -- presently it's just 
a blanket ref.

 > Also is this TODO resolved?

we're working on it. I think we should alloc a new sip error value, as has been 
proposed by Hannes. just need to choose one.

 > 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.

agreed, good catch.

 > 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.

ah! yeah, another good catch. Also we should probably reference section 13.4 of 
rfc4474.

thanks for your review,

=JeffH

_______________________________________________
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: Mon, 09 Jul 2007 15:42:16 -0700

> -------- Original Message --------
 > Subject: [Sip] SIP SAML Review by Richard Barnes
 > Date: Wed, 20 Jun 2007 23:44:26 -0400
 > From: Richard Barnes <[email-masked]>
 > To: IETF SIP List <[email-masked]>, 	Hannes Tschofenig <[email-masked]>
 >
 >
 > Figure 2:
 > In the INVITE messages, the AoR in the From: header should be
 > "sip:[email-masked]"

ok.

 > 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.

ok.

 > 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?

nominally yes, will investigate.

 > 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."

good catch.

 > 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.

another good catch.

 > 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.

will re-think with eye towards mandatory default behavior.

 > Section 6.1.4.1.3:
 > The SHOULDs in this section should be should be MUSTs.

nominally agree.

 > 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.

nominally agree.

 > Section 7:
 > This binding doesn't really have anything to do with SIP.

agreed.

 > Could we just
 > exclude SIP from the name?

sure.

 > Maybe this could be the IETF standard URI
 > binding of SAML.

that's an interesting thought, tho I wonder if it is worth the effort to try to 
do as an I-D on its own -- it's so small to specify that it can easily be 
included by-value in other specs, but of course then there might be skew, but 
would that in actuality be a problem, ... etc. And more precisely it's an 
http-uri-based one. there could be other needs for schlepping saml assertions 
via http in other fashions.

thanks for your insightful review.

=JeffH