I've been a little quiet but following the progress... (will be there at next OGF), here is my 2 cents based on my experience inline.. On Wed, Jun 20, 2012 at 4:40 AM, Henrik Thostrup Jensen <htj@nordu.net>wrote:
Hi
I'm going to throw a lot of fruit here...
On Tue, 19 Jun 2012, Inder Monga wrote:
On Documents structure, new services and security.
Slide 2:
When was confidentiality thrown out the window as a requirement? I do think privacy matters.
Slide 3:
Could you pleeeease stop with the proxy argument. It is completely bunk.
Yes, there are SSL/TLS proxies. And they are very useful. They offload the decryption to other CPUs or machines. They are often also quite easy to configure, which is great for admins. In almost all cases the proxy runs on the same machine as the application or a machine next to it.
There is no one forcing you to run a proxy. It is perfectly possible to run SSL/TLS within the application.
There is abselutely _nothing_ preventing proxies with WS-Security. It is just more clumsy since it is at message level and not transport level.
With your level of reasoning NSI should be implemented in the ASIC in routers. Only then will we have true end-to-end security.
Also, HTTPS is not a transport protocol, but lets get moving.
Slide 4:
Saying that WS-Security is the only option is simple not true.
For SOAP it's pretty much the only one that survived that plays well with
Using Transport-Level Security (TLS) is often sufficient if messages are point to point. Where WS-Security is very useful is when messages are handled by 3rd parties and we want to keep the content private. An example for this would be NSA relays where a message would be forwarded on behalf of another NSA. I'll let you guys judge if it's a required features personally I don't think it would happen often. the stacks, But you can always have a security proxy in front of the service doing the handshake (OAuth, SAML ECP, etc.) and not care about message security.
Slide 6:
SAML? Seriously? :-). Why do we need federated authentication?
Here I must ask the same question, why federated authentication? It depends on the level of traceability we want to achieve with the users. If it is domain to domain delegation and it's the NSA that is acting on the end user's behalf I don't think it's needed however if every domain want to track the end user and apply policies in this regard federated identity is desirable.
It is my impression that SAML is largely being superseeded by OAuth 2.0 these days (which is quite different from OAuth 1 btw.).
This is mainly do to the fact that REST and simpler interfaces are getting more traction (on that when can we expect a REST API for NSI ;) ) they are easier for developers and have less dependencies on the libraries and SOAP stacks. OAuth 2.0 adds what was needed for federated identity and is a lot nicer than 1.0. I use both OAuth and SAML from a middleware perspective and I don't see them as "competing solutions". SAML will give you assertions on which you apply policies whereas OAuth provides federated login with "delegate" access to resources.
Slide 9:
Username+password & X509 & SAML. All of them? Oh joy. Why don't we just say that we don't know or couldn't decide.
Well theses are the default WS-Security profiles... In theory it's nice to all have that but from experience it would be nicer to have a consensus on what will actually be used for the NSAs. This is especially important when it comes to the implementation of the solution and authorization.
Slide 10:
WS-Security does not establish a secure transport. That is a very fundemental part of message level security. FWIW there is actually WS standard for establishing secure transports with SOAP called WS-SecureConversation, but I don't want to give you too many good ideas.
Ideas or nightmares.. ;) WS-SecureConversation was indeed used for the TLS
handshake and was used quite a bit by GT4 back in the days. Not many people use it these days, they simply use HTTPS with proper certs like the rest of the web.
Slide 11:
What.. we've decided now?
I really really hope you mean "SAML assertions for AuthN" and not authZ. We still want to allow NSA to decide what they authorize, right?
I think he meant AuthZ, probably referring to a XACML engine and policies
matched to the SAML assertions.. On a final note I agree with both the slides and Henrik comments and think it is merely a matter of perspective however my only recommendation is to keep it as simple as possible and "less is more". Meaning that I would rather sacrifice flexibility and I am unsure if WS-Security is really the best option for NSI's purpose but because it's SOAP-Aligned (at least for now) I think WS-Security would be the simplest to implement. A final note, in the past I've had issues between SOAP security stacks, (rampart, cxf, twisted, etc. ) between java stacks and the "p languages perl/python/php) mainly because of small differences in the implementation. but my main reason for replying comes to this: If doing point-to-point communications message-level security is overkill and useless. If messages are routed than it's required and WS-Security is IMO still the best way to go.. Have a nice meeting, Mathieu
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
______________________________**_________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/**listinfo/nsi-wg<https://www.ogf.org/mailman/listinfo/nsi-wg>