Subject: AW: [Sipping] WGLC: draft-ietf-sipping-trait-authz-01.txt

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 20 Jun 2005 09:18:02 +0200

hi jeroen, 

please find a comment below: 

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Jeroen van Bemmel
> Gesendet: Sonntag, 19. Juni 2005 21:59
> An: sipping
> Betreff: Re: [Sipping] WGLC: draft-ietf-sipping-trait-authz-01.txt
> 
> 
> Hi,
> 
> I am posting an open question as a comment: how do you see 
> interaction 
> between this and session policies 
> (http://www.ietf.org/internet-drafts/draft-ietf-sipping-sessio
> n-indep-policy-02.txt)
> 
> Here's one example of how it could work: using the session policies 
> framework a proxy can direct a UA to a policy server to 
> obtain a session 
> policy. The UA retrieves the policy, should adjust its INVITE SDP and 
> re-submits the request, this time adding a header to indicate that it 
> visited the policy server. That presents an open issue: how 
> does the proxy 
> determine that the UAC now indeed conforms to the policy?
> 
> In the current draft, policy enforcement is considered out-of-scope. 
> However, I think that a trait-based authorization token could 
> solve this, 
> i.e. the policy server could return the policy as a signed 
> token (or return 
> a separate token along with the policy), and the client would 
> have to send 
> this token along to the proxy. The proxy would inspect the 
> token, confirm 
> that it comes from a trusted source and use it as a basis to 
> enforce the 
> policy

this seems to be right.

> 
> We have been experimenting with this in the context of Web 
> services.
> One of 
> the things we found is that communicating policies following 
> the current 
> standards (i.e. signed SAML assertions) leads to very verbose, large 
> documents.

it depends on the content of the assertion (and whether you use assertions at all). 
if you use xml document then everything tends to grow in size.

if you use an artifact then the size of the "token" is very small, in fact it is only a pointer to the assertions itself. 

> You may want to consider this in your requirements 
> (and it gets 
> even worse with multiple assertions), I expect that adding 
> such an assertion 
> to a SIP request easily makes it larger than the magic 1300 
> bytes size for 
> UDP transports.
udp transport and the usage of xml does not nicely play together. the artifact would offer a nice tradeoff.  

ciao
hannes

> 
> Regards,
> 
> Jeroen van Bemmel, Lucent Technologies
> 
> ----- Original Message ----- 
> From: "Gonzalo Camarillo" <[email-masked]>
> To: "sipping" <[email-masked]>
> Cc: "Rohan Mahy" <[email-masked]>; "Jon Peterson" 
> <[email-masked]>; "James M. Polk" <[email-masked]>; "Dean 
> Willis" <[email-masked]>
> Sent: Sunday, June 19, 2005 8:41 PM
> Subject: [Sipping] WGLC: draft-ietf-sipping-trait-authz-01.txt
> 
> 
> > Folks,
> >
> > we would like to working group last call the following draft:
> >
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-trait-a
uthz-01.txt
>
> This WGLC will finish on July 8th. Please, send your comments to the
> authors and to the list.
>
> Thanks,
>
> Gonzalo
> SIPPING co-chair
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP 

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

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

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 20 Jun 2005 20:22:14 +0200

Hi Hannes,

<snap>
> services. One of  the things we found is that communicating policies 
> following
> the current standards (i.e. signed SAML assertions) leads to very verbose, 
> large
> documents.

| it depends on the content of the assertion (and whether you use assertions 
at all).
| if you use xml document then everything tends to grow in size.

| if you use an artifact then the size of the "token" is very small, in fact 
it is only a pointer to the assertions itself.

You are right that using pass-by-reference rather than pass-by-value could 
alleviate the size issue, however what do you do then about policy rules 
that are to be interpreted by the client (as in the session policies draft)? 
It seems a bit double to direct the client to a policy server, which then 
directs it to some other server for resolving the artifact.

I would suggest a hybrid approach: use a policy that contains some 
parameters to be interpreted by the client, and possibly an opaque artifact 
that is to be passed in each request. Some requirements for this artifact 
would be:

- it should contain a timestamp for replay protection
- it should contain the identity of the client to which it was given
- it should be signed
- it MAY include an indication of the source that issued it (e.g. id of its 
certificate), this could also be implicit

I'm thinking of something like an MD5-converted encrypted URL with some 
parameters

Depending on the trust model the complete token could optionally be signed 
too for verification by the client, but it may also rely on other layers 
(e.g. using https)

I would personally choose to have the proxy return such a policy instead of 
a reference to some policy server ( i.e. it sends an error reply with the 
policy as body, and maybe the artifact in some header). The client should 
indicate support for this in its Accept header. Benefit of this is that it 
does not burden the client with yet another protocol to implement for 
talking to a policy server. And for SDP related policies, why not have the 
proxy return an SDP description of what it allows (since the client already 
knows how to parse SDP) instead of adding a new XML format?

Regards,

Jeroen