[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



hi jeroen, 

please find a comment below: 

> -----Ursprüngliche Nachricht-----
> Von: sipping-bounces at ietf.org 
> [mailto:sipping-bounces at ietf.org] 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" <Gonzalo.Camarillo at ericsson.com>
> To: "sipping" <sipping at ietf.org>
> Cc: "Rohan Mahy" <rohan at ekabal.com>; "Jon Peterson" 
> <Jon.Peterson at neustar.com>; "James M. Polk" <jmpolk at cisco.com>; "Dean 
> Willis" <dean.willis at softarmor.com>
> 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP