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