RE: [security-services] SAML enhancement proposal from NSN

Hello Hal and et al,

Thanks you for the comments. I hope that the following the responses resolve your concern and clarify some of the points. Please see the response under heading [NSN] below.

Regards,

Thinh

I have significant concerns about the Attribute Management Protocol proposal.

SAML has avoided any kind of update protocol for good reasons. I am not ready to say I oppose ANY such scheme, but there are a number of matters that need to be considered.

1. The proposal appears to duplicate functionality defined in other standards or open proposals, including

It may well be that this proposal provides necessary functionality missing from any other specification or that there are reasons why doing it in SAML is superior to any other approach, but this needs to be documented explicitly.

[NSN] Aftter further analysis of these two other solutions and our proposal, we can summarize the following:

SPML defines two bindings: SOAP or file. It is not able - like SAML - to be transported via HTTP Post or Redirect, nor does it support the concepts of including an issuer (the entity that created the request), privacy (encrypting parts of the request), security (digitally sign parts of the request), or similarities. It is thought for enabling two entities that are closely related to each other (e.g. enable an IdP to communicate with a database, enable two SPs to exchange information about their data within the *same domain*).

It further does not contain concepts like validity intervals (valid between two dates), expiration, etc. It is to be seen as database synchronization protocol. (Compare it to SQL, but with LDAP/X509 structure and a little bit more… formal :-) )

CARML is a protocol to enable applications to communicate with each other. It is an administration protocol with a huge variety of possible methods, that all have to be understood by both parties. Further, they have to have a "common understanding" on policies, each others concepts, etc. That's not the case in NSN use cases where we have an external service provider, operates by maybe a small company, and the IdP, operated by a telco that wants to "hide" ist internals and of course also ist database, structure and concepts.

Of course, storing attributes at IdP could be handled by another protocol. The drawback is that both parties (IdP and SP) have to be extended by another protocol and maybe also their specific contexts (authentication, protocol specific needs, etc.) - if SAML would support it, everything is already there.

NSN intention is to create a very simple and well understandable message to alter SP specific or allowed common attributes of a user. This proposal is not trying to duplicate other cappabilities from CARML or SPML, such as read, find, search compare, add, delete. Because some of the these capablities already existed in the SAML like, read and find. The marketplace is requiring an ease of implementation and reduction the network complexity by not requiring to understanding the database structure and concept of the IdP, reducing number of supporting protocols, etc..

2. The semantics of updates in a distributed environment are always complex and requirements and level of required support must be made explicit.

Off the top of my head:

What are the semantics of the update? Exactly what fields in the assertion are deemed to be being updated? Can a new Subject be added or only attributes be updated? Can the issuer be changed? Validity Interval? other Conditions? Can Attribute be added or only existing ones changed?

What are the error semantics? How are partial errors handled and signaled?

What are the transaction semantics? Is the update atomic?

When is the update expected to be visible? How does it interact with replication? What about conflicting updates?

Is modify the only required action? What about Create? Delete?

[NSN] Only the fields that need to be updated will be in the request. Subjects can neither be changed nor updated, because there already exists a message protocol in SAML for doing this. The issuer is the one that creates the message - why should this be changed ? Finally - because the message is signed by the issuer, no fields can be changed on the transport between SP and IdP.

Attributes shall not be added "on the fly" because this would create a privacy and security risk. The attributes that may be stored have to be previously agreed on by both parties (the same way as they were agreed for the attribute query). Conditions and Validity intervals are a good idea and worth an extension of the idea.

Partial errors are signaled by containing the "old" values in the response. If there is a field within the request that this is a transaction and therefore atomic, the response would not be a "Success" with old values (for the failing attributes) but a "Failure" with a SAML error code. (As already defined by the standard). Because our idea is about "service provider specific" updates, it is very unlikely to find "concurrent" updates. If there is one, the later one will override the previous one. (Like it is the same for attribute requests etc.)

3. Authorization is likely to be complex, involving not only fine grained access control and forms of delegation. (Nothing XACML can't handle of course.)

Authentication of the SP and likely the User is going to be a lot more critical.

Is control to the attribute/action level required?

At a minimun, this scheme will make the IPD threat model a lot more complex.

I am sure there are other issues as well, but I wanted to mention my concerns prior to the call today.

[NSN] We do not see these issues a problem, because it would not affect the Attribute Management Protocol. And, it is already part of the standard.

security-services message