Subject: [Sip] SIP SAML: Issue #9 - Passing SAML Assertions Per Value

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Oct 2006 15:54:32 +0200

Hi all,

we had some discussions about a SIP proxy adding a SAML assertion to the 
  SIP header. See issue#9 at http://www.tschofenig.priv.at:8080/saml-sip/issue9

The SIP Payment draft defines a profile that allows SAML assertions to 
be added by the end point. I suggest to consider the SIP Payment 
mechanism. I am not so sure whether we should move the content of the 
SIP Payment draft into the SIP SAML draft. I would prefer to keep the 
functionality of the end host to request SAML assertions in the SIP 
Payment draft for now.

This also refers to issue#10.
http://www.tschofenig.priv.at:8080/saml-sip/issue10

Suggestions?

Ciao
Hannes

_______________________________________________
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: Mon, 16 Oct 2006 14:03:54 -0700

Hi Hannes;

I have been evaluating the current SIP-SAML profile and for any
information that may be used by intermediaries for routing purposes,
it may be better to include the SAML assertion by value. SAML can
be included in the message body, but that would require UAC to be
SAML aware which might not be a reasonable as it adds a lot of load
to UAC to support SAML, thus to reduce the complexity, adding it to
the SIP header may be a reasonable approach.(Despite the message
size implosion etc., I do think there is some benefits, as have been
discussed on GEOPRIV on a similar context for location information).

But before I go on, trait-authz requirement with MUST strength
says that the solution MUST provide a way to prevent unauthorized
parties from viewing the contents, which would not hold true if we
include the SAML assertion in the header.

REQ 11. from RFC4484(trait-authz)

" The mechanism MUST provide a way of preventing unauthorized

  parties (either intermediaries or endpoints) from viewing the
  contents of assertions."

I personally think that the justification for the inclusion of the SAML
assertion
in the header really depends on what values will be carried in SAML
assertion.
If the sender or the originating domains see no threat in sharing the
information
with the rest of the world(say cpc values?), I think it is okay to set
the assertion
in the header thereby all the entities can see the assertion along the
signaling
path. If not current SIP-profile should be used to make sure further
authentication
of the party requesting the SAML can be provided to make sure the
assertion is
not given to an unwanted parties.

Regards
Shida

Hannes Tschofenig wrote:
> Hi all,
>
> we had some discussions about a SIP proxy adding a SAML assertion to
> the SIP header. See issue#9 at
> http://www.tschofenig.priv.at:8080/saml-sip/issue9
>
> http://www.tschofeFrom [email-masked] Mon Oct 16 17:49:01 2006
Date: Mon, 16 Oct 2006 14:03:54 -0700
From: Shida Schubert <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Subject: Re: [Sip] SIP SAML: Issue #9 - Passing SAML Assertions Per Value
Cc: IETF SIP List <[email-masked]>
Reply-To: [email-masked]

Hi Hannes;

I have been evaluating the current SIP-SAML profile and for any
information that may be used by intermediaries for routing purposes,
it may be better to include the SAML assertion by value. SAML can
be included in the message body, but that would require UAC to be
SAML aware which might not be a reasonable as it adds a lot of load
to UAC to support SAML, thus to reduce the complexity, adding it to
the SIP header may be a reasonable approach.(Despite the message
size implosion etc., I do think there is some benefits, as have been
discussed on GEOPRIV on a similar context for location information).

But before I go on, trait-authz requirement with MUST strength
says that the solution MUST provide a way to prevent unauthorized
parties from viewing the contents, which would not hold true if we
include the SAML assertion in the header.

REQ 11. from RFC4484(trait-authz)

" The mechanism MUST provide a way of preventing unauthorized

  parties (either intermediaries or endpoints) from viewing the
  contents of assertions."

I personally think that the justification for the inclusion of the SAML
assertion
in the header really depends on what values will be carried in SAML
assertion.
If the sender or the originating domains see no threat in sharing the
information
with the rest of the world(say cpc values?), I think it is okay to set
the assertion
in the header thereby all the entities can see the assertion along the
signaling
path. If not current SIP-profile should be used to make sure further
authentication
of the party requesting the SAML can be provided to make sure the
assertion is
not given to an unwanted parties.

Regards
Shida

Hannes Tschofenig wrote:
> Hi all,
>
> we had some discussions about a SIP proxy adding a SAML assertion to
> the SIP header. See issue#9 at
> http://www.tschofenig.priv.at:8080/saml-sip/issue9
>

---

From: Jeff Hodges <[email-masked]>
Date: Sat, 21 Oct 2006 07:50:35 -0700

Shida wrote:
 > it may be better to include the SAML assertion by value.

sure, if there's info in the SAML assertion needed by some entity for some 
decision, it'll be more efficient overall to have it (the SAML assertion) 
conveyed directly in the SIP message by value rather than by reference.

 > SAML [assertion] can
 > to UAC to support SAML,

well, maybe or maybe not, it depends. There are shipping cellphones today (eg 
from Nokia) that support Liberty ID-WSF (full-on XML-based web services stack 
with SAML-based security features), so it's certainly not impossible for 
physically small battery-powered devices to support "complex" XML-based 
protocols and objects. And it's possible for developers in the mobile device 
biz to write the necessary code.

There are likely some scenarios where it makes sense for a UAC to directly 
obtain SAML assertion(s) attesting to the user's identity and/or other aspects 
of the user and/or UAC or whatever.

 > thus to reduce the complexity, adding it to

Rather than just complexity, its perhaps driven more by deployment scenarios to 
have the UAS being responsible for incorporating security attestation and 
assurance to a SIP request, as described in RFC4474, which the present 
draft-ietf-sip-saml-00 "composes" with.

I'm taking what you said directly above, "...adding it to the sip header..." to 
be referring to having intermediaries do so, eg a UAS.

 > include the SAML assertion in the header.

Not necessarily, there are ways to address such a requirement. Tho worrying 
about confidentiality at this point is putting the cart before the horse it 
seems to me (see next item)

 > assertion in the header really depends on what values will be carried in
 > SAML assertion.

I respectfully disagree, in that there is a higher-level SIP protocol 
architectural justification/question that needs to be addressed first, and that 
is:

   Is it legit from a SIP protocol architectural perspective to specify
   SIP extensions (eg new SIP protocol header fields) that may, or are
   expected to, contain data objects of nearly arbitary size (eg O(100s)
   to O(1000s) octets) and arbitrary complexity?  aka BLOBs (Binary Large
   OBjects)

I have been informed verbally by some that specifying a general-purpose 
approach for accommodating conveyance of such BLOBs (whether or not they are
actually conveyed in a "binary" or "textual" encoding let's just call the BLOBs 
for the purposes of discussion) would be a violation of the "SIP protocol 
architecture" (due to "..recasting bodies as headers..") and would likely lead 
over time to just conveying everything in header fields, and thus it won't ever 
get consensus or be codified. The most concise public example of this argument 
I can find is this message on this list from this last summer..

   RE: [Sip] Location header
   From: "Peterson, Jon"
   http://www1.ietf.org/mail-archive/web/sip/current/msg15362.html

Alternatively, there are apparently some (including yourself, shida) who feel 
that conveying-BLOBs-in-SIP-header-fields is not necessarily a violation of the 
"SIP protocol architecture". The most concise public example of this I've found 
is this message in response to the above cited one..

   Re: [Sip] Location header
   From: Henning Schulzrinne
   http://www1.ietf.org/mail-archive/web/sip/current/msg15363.html

As far as I can tell from perusal of the SIP mailing list, this discussion 
isn't convincingly decided one way or another at this point. If it is, then the 
chairs should make it clear because apparently not everyone realizes it.

Plus, there are some gnarly security aspects of including certain types of 
information "by-value", as you note in your message (portions above), and which 
the "retargeting" SIP feature especially highlights (see 
draft-peterson-sipping-retarget-00 (expired)). So it needs to be done carefully.

 > If not current SIP-profile
 > should be used to make sure further authentication of the party requesting
 > the SAML can be provided to make sure the assertion is not given to an
 > unwanted parties.

Just to be clear, I'm assuming you meant "SIP SAML profile spec" when you wrote 
"SIP-profile".

And this brings up a set of points about the general topic of having a relying 
party retrieving various objects "by reference" from other party(ies). We've 
acquired some experience with this in actual deployments in the SAML world 
courtesy the SAML "Browser artifact profile". We often refer to the operation 
of dereferencing the reference as a "callback".

There's a whole range of operational and application implementation issues that 
can come up with callbacks, detailed below.

Given these issues, it seems we should think carefully before obviating any 
conveyance of BLOBs in SIP header fields "by-value", unless it's already 
decided and I missed it.

=JeffH
------

Application Implementation and Deployment Operational Issues with Callbacks
(courtesy Scott Cantor)

- firewalls

Operationally, it can be a hassle for many deployers to deal with their
networking staff, or they are forced into ugly and exotic proxying and port
forwarding that makes deployment harder or impossible when TLS is required.

- state mgmt

Callbacks often introduce statefulness. Statefulness is a scaling problem in
high end systems, and makes clustering an implementation much harder.
Stateless software can be horizontally scaled very cheaply without single
points of failure. The worst kind of callback is the SAML kind, a one-time
artifact. That requires instant replication, which isn't practical in WAN
clusters, which is why SAML artifacts include an endpoint index.

- authentication / configuration

Most callback designs require authentication of at least the server, and
sometimes the client. Configuring TLS is very hard for mortals, even just
server side, and if you lose that, you lose confidentiality even if you sign
messages.

You also run into problems in some communities because people insist on
using X.509/PKIX, and that leads to people making decisions like forcing
people to install SSL servers distinct from their existing web sites to use
the special certificates you force on them. Not that I know of anybody doing
that <cough>. That also in turn ties back to firewalls.

Push models sometimes require key exchange for allowing encryption, but
experience shows people have less problems with configuring that because
it's self-contained configuration. It also allows for one-way trust models
that rely on the client for MITM protection.

- data coordination

In some applications, callbacks may be triggered to party A by a message
from party B. That requires A and B share state, knowledge,
pre-configuration, etc. If A and B are loosely coupled, that creates
problems that push models don't have.

An example is naming. I issue a certificate for Bob and you want to ask
somebody else about Bob. If that somebody and I don't share the same notion
of who/what Bob is, chaos ensues.

An alternative model is for somebody else to push their notion of Bob to me 
where I can bind that information to my notion of Bobness, e.g. even if my name 
for Bob is Alice.

---
end