[Nsi-wg] Presentations from today

[Mathieu Lemay]

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 at 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.
>
>
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.




> 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
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 at ogf.org
> https://www.ogf.org/mailman/**listinfo/nsi-wg<https://www.ogf.org/mailman/listinfo/nsi-wg>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120620/f83349bd/attachment.html>