Subject: [Sip] comments on draft-ietf-sip-saml-00

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jul 2006 15:29:35 -0400

Overall, this is a HUGE improvement over draft-tschofenig-sip-saml-04, 
which is the last version I read (I see that -05 was similar to 
draft-ietf-sip-saml). This looks like a viable solution overall, and I 
like how it dovetails with sip-identity.

Major comments:

* I'm a little worried that the SAML assertion itself doesn't include 
any content from the SIP message which clearly limits its scope of 
applicability to the request. You are relying on authentication via 
sip-identity for that, but there are attacks where this won't work.

For example, consider a rogue proxy or MITM which sees a SIP request fly 
by. The AS was executed by an upstream proxy, so this request has an 
Identity and Identity-Info header field. The proxy modifies the 
Indentity-Info header field, which contains a URL to an older assertion 
generated by the AS for the same subject, say, for a previous call it 
just made.

This is not a major threat, but there may be others like it. Is there 
harm in including things like call-id, contact and other parameters into 
the saml assertion so they are signed too?

* I'm not clear on how this mechanism works with older sip-identity 
implementations. The main issue is whether the URI in the identity-info 
header field will return just a certificate, as specified in 
sip-identity, or whether it returns a saml assertion. An older 
sip-identity verifier will expect a certificate but it will get an 
assertion if the AS implements sip-saml. Perhaps you are assuming that 
the Accept headers or something are used for this? Somehow this needs to 
be handled.

 > 6.1.4.1.3.  Element: <Conditions>
 >
 >    The <Conditions> element SHOULD contain an <AudienceRestriction>
 >    element, which itself SHOULD contain an <Audience> element.  The
 >    value of the <Audience> element SHOULD be the same as the addr-spec
 >    of the SIP request's To header field.

Hmm. Here is our infamous retargeting problem again. If the request is 
retargeted, does this mean that the assertion cannot be used by the 
forwarded party? This restriction doesn't exist for normal sip-identity.

Minor comments:

> The scope of this specification is:
> 
>    o  Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such
>       that a subject's profile attributes, and their domain's
>       certificate, can be conveyed to a relying party using SAML.  In
>       doing so, satisfy the requirements outlined in [I-D.ietf-sipping-
>       trait-authz], and compose with [I-D.ietf-sip-identity].

perhaps I've misunderstood, but don't we also need to specify a SIP SAML 
binding?

>  SIP-specific SAML profile(s) and binding(s).  This is technically
>    straigh-forward as both SAML and SIP are explicitly extensible.

straightforward

> [RFC3261].  Depending on the chosen SIP security mechanism
>            either digest authentication, S/MIME or Transport Layer
>            Security is used to provide the AS with a strong assurance
>            about the identity of Alice.

well, TLS in this use case is not normally used to provide the AS with 
the identity of ALice. Perhaps you are referring to mutual 
authentication with tls? Or maybe you just mean digest over tls?

>  signature" for the message and add Identity and Identity-Info
>            headers to the message.  The AS also at this time constructs

I feel like a broken record, but its header field and not header

* sections 6.1.3, 6.1.2 and 5 all seem pretty redundant, as they contain 
the same flow with nearly the same levels of detail. Are all three needed?

>  Attribute: NotOnOrAfter
> 
>       The value of the NotOnOrAfter XML attribute MUST be set to a time
>       instant later than the value for NotBefore.

guidance on how to set this?

>   This section specifies the "SAML HTTP-URI-based SIP Binding",
>    (SHUSB).

SHUSB? Geez, this acronym is awful.

> Section 3.7.5.4 Error Reporting:
> 
>       All SHOULDs in this section are to be interpreted as MUSTs.
> 

This is somewhat mysterious. Is there something SIP specific which would 
cause you to want to do this, or just a beef with the fact that 
everything there is a SHOULD and not a MUST? Also perhaps a few words 
about whats in that section would be helpful.

Indeed its not obvious to me why we can't just use the existing SAML URI 
binding if we're just doing a vanilla http query to retrieve the assertion.

> 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
>    [I-D.ietf-sip-identity].

I read this as being that this is the literal AoR, i.e., 
sip:user@domain. But, in the example later on:

> 1 <Assertion ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
>     2    IssueInstant="2003-04-17T00:46:02Z" Version="2.0"
>     3    xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
>     4    <Issuer>
>     5       example.com
>     6    </Issuer>
>     7    <Subject>
>     8       <NameID
>     9         Format=
>    10         "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
>    11         [email-masked]
>    12       </NameID>

there is no sip:, and the format attribute has a URN which explicitly 
says emailAddress and not SIPURI. I think this should be a SIP URI.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Shida Schubert <[email-masked]>
Date: Fri, 07 Jul 2006 22:04:36 -0700

Hi Jonathan;

My comments inline.

Jonathan Rosenberg wrote:
> For example, consider a rogue proxy or MITM which sees a SIP request
> fly by. The AS was executed by an upstream proxy, so this request has
> an Identity and Identity-Info header field. The proxy modifies the
> Indentity-Info header field, which contains a URL to an older
> assertion generated by the AS for the same subject, say, for a
> previous call it just made.
>
> harm in including things like call-id, contact and other parameters
> into the saml assertion so they are signed too?
>
> implementations. The main issue is whether the URI in the
> identity-info header field will return just a certificate, as
> specified in sip-identity, or whether it returns a saml assertion. An
> older sip-identity verifier will expect a certificate but it will get
> an assertion if the AS implements sip-saml. Perhaps you are assuming
> that the Accept headers or something are used for this? Somehow this
> needs to be handled.
>
I asked the exact question on the SIP-SAML design team ML as well as in
the last meeting.
Currently as you mentioned, there is no indication on whether the URI
referred by identity-info
header points to a certificate or sip-identity.

As far as I understood from the reply I got was that because SAML is
based on federation or
bi-lateral agreement, AS should know whether the target will understand
the SAML. So there is
no problems.

Although, if call is forwarded to a domain which is not part of the
federation, it may cause
some issues.

There are few other issues with the current SIP-SAML spec if it was to
be used to convey
information that would affect a routing decision on the signaling path.
The issues are addressed
on the draft which evaluates the profile defined in the SIP-SAML spec to
convey CPC related
information.

http://www.ietf.org/internet-drafts/draft-schubert-sipping-saml-cpc-01.txt

BTW it's not currently mentioned in the draft, but if more than one
asserting party exists on
the signaling path that needs to add artifacts(URI to the assertion),
the current SIP-SAML
might not work as sip-identity only allows one uri to be referred AFAIK.

> forwarded party? This restriction doesn't exist for normal sip-identity.
Agreed.
Same can be said if the assertion is to be used by the intermediaries to
alter the
routing of the call.
> perhaps I've misunderstood, but don't we also need to specify a SIP
> SAML binding?
>
> * sections 6.1.3, 6.1.2 and 5 all seem pretty redundant, as they
> contain the same flow with nearly the same levels of detail. Are all
> three needed?
>
>
>> Attribute: NotOnOrAfter
>>
> This is somewhat mysterious. Is there something SIP specific which
> would cause you to want to do this, or just a beef with the fact that
> Indeed its not obvious to me why we can't just use the existing SAML
> URI binding if we're just doing a vanilla http query to retrieve the
> assertion.
>

I addressed this a while ago as well.

Regards
Shida