Subject: [Sipping] comments on draft-peterson-sipping-role-authz-01

From: "Eagan, Christopher" <[email-masked]>
Date: Fri, 21 Nov 2003 14:15:13 -0500

I think this draft as a whole is great, and I think a scheme that meets these requirements will be helpful in extending SIP to more applications.  The only issues I have it....

--------------------
Requirement #6: "Proxy servers should have a way to inspect assertions..."

Why not "must have a way..."?  Or "there must be a mechanism for proxy servers to inspect assertions (that may or may not have to be activated, depending on the specific network).

-----------------------
Requirement #7: "The mechanism must have a single baseline mandatory-to-implement authorization assertion scheme".

Why not just have a toolkit that UA's can implement on a needs basis, along the ability to query/answer questions about their capabilities w/ regards to trait based authorization?  There are different levels of security requirements for different examples of where this scheme could be used.  For example, the scenario of asserting the trait of professor in the chemistry department versus asserting the trait that one is a commander in a police department.  Is this a trade-off of requiring more work for implementors at the benefit of more reliable interoperability?  (or am I way off and reading the requirement wrong?)

-----------------------
Requirement #11: "An assertion must have security properties that can prevent unauthorized parties from viewing the contents of the assertion."

I think you mean this as a requirement for the scheme but possibly optional to activate but I think it could be clearer.  Securing the contents of an authorization seems like it may be unecessary in some cases (like possibly asserting you're a professor in the chemistry department).  Possible alt verbage for #11:  "The scheme must provide a mechanism that can prevent unauthorized parties from viewing the contents of the assertion".

------------------------
Requirement #15: "It must be possible for a UAS or proxy server to reject a request that lacks an authorization assertion..."

I'm not reconciling this with #6, that says proxy servers >>should<< have a way to inspect assertions.  Is this a requirement that the proxy server makes sure an assertion is present in a message? or that it is both present and valid?  I would normally assume the latter, except for requirement #6.

Thanks!

Chris

_______________________________________________
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: "Peterson, Jon" <[email-masked]>
Date: Fri, 21 Nov 2003 14:12:44 -0600

> I think this draft as a whole is great, and I think a scheme 
> that meets these requirements will be helpful in extending 
> SIP to more applications.  

Great, thanks!

> The only issues I have it....
> 
> --------------------
> Why not "must have a way..."?  Or "there must be a mechanism 
> for proxy servers to inspect assertions (that may or may not 
> have to be activated, depending on the specific network).
> 

Agreed that must is better, and that this requirement could use some
rewording. We aren't really using RFC2119 language in this draft, and
perhaps we should, just to be more specific about these matters.

> -----------------------
> Requirement #7: "The mechanism must have a single baseline 
> mandatory-to-implement authorization assertion scheme".
> 
> Why not just have a toolkit that UA's can implement on a 
> needs basis, along the ability to query/answer questions 
> about their capabilities w/ regards to trait based 
> authorization?  There are different levels of security 
> requirements for different examples of where this scheme 
> could be used.  For example, the scenario of asserting the 
> trait of professor in the chemistry department versus 
> asserting the trait that one is a commander in a police 
> department.  Is this a trade-off of requiring more work for 
> implementors at the benefit of more reliable 
> interoperability?  (or am I way off and reading the 
> requirement wrong?)
> 

The requirement isn't that we accept some particular set of traits (like
'academic' versus 'military' or something), but rather that there be one
format for assertions that all implementations support. SAML is given in the
draft is an example - any number of trait sets can be supported by SAML. The
issue is that if some implementations use SAML, and others use (I don't
know) attribute certificates, or something, to express these traits, then
they won't be interoperable.

> -----------------------
> Requirement #11: "An assertion must have security properties 
> that can prevent unauthorized parties from viewing the 
> contents of the assertion."
> 
> I think you mean this as a requirement for the scheme but 
> possibly optional to activate but I think it could be 
> clearer.  Securing the contents of an authorization seems 
> like it may be unecessary in some cases (like possibly 
> asserting you're a professor in the chemistry department).  
> Possible alt verbage for #11:  "The scheme must provide a 
> mechanism that can prevent unauthorized parties from viewing 
> the contents of the assertion".
> 

I'm fine with your suggested wording.

> ------------------------
> Requirement #15: "It must be possible for a UAS or proxy 
> server to reject a request that lacks an authorization assertion..."
> 
> I'm not reconciling this with #6, that says proxy servers 
> >>should<< have a way to inspect assertions.  Is this a 
> requirement that the proxy server makes sure an assertion is 
> present in a message? or that it is both present and valid?  
> I would normally assume the latter, except for requirement #6.
> 

Granted, it is the latter, and we should fix 6 and this one accordingly. It
is possible, of course, that a particular proxy server would not be
authorized to inspect an assertion (I might want only one proxy in a request
path to be able to inspect it), so we don't want to make 6 say "all
assertions must be readable by all proxy servers", but if a proxy server
must inspect the assertion, and cannot do so or finds it to be invalid, then
that may be grounds to reject a SIP request.

Jon Peterson
Neustar, Inc.