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

[Jeff Hodges <[e-mail]>]

Shida wrote:
 >
 > 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.

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

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

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.


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

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)


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

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







_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip