That may be true in some cases, but in this case, they are not defending against traffic analysis, which requires the ISP to maintain state about lots of data flows and analyse it in near-real time. If you look at what the BitTorrent devs are doing, they are obfuscating the peer list in the protocol, to prevent packet inspection from identifying the connection as BitTorrent. Interestingly, they are also intentionally using weak crypto (for performance reasons) - the goal being simply to raise the detection bar, not to create a cryptographically secure protocol.
Sooo.... you're quite happy that useful models can be built that make predictions about human intentions. But you don't think it works with the climate, because those dang scientists keep adjusting their models until they give predictions that fit. And the difference between these two is...?
Freudian slips! "but I would assert that it is being used as part of an authorization process, which is how the security it provides would be judged." and "The system gives two "authorization" paths"
I meant to say "an authentication process" and "authentication paths"!
Well, we're clearly coming from different perspectives on this one. I don't deny that it *is* a capability - but I would assert that it is being used as part of an authorization process, which is how the security it provides would be judged.
In terms of a security risk analysis of this system, I would want to know the strength of protection that this system allows for its users and the content being protected. The system gives two "authorization" paths to access the resources of a user: (1) log in with a password (2) use the USB key to recover a session. From my perspective, I don't care about the underlying mechanisms - I want to know that all the paths meet a minimum security standard.
Taking this experiment a bit further: the username / password combination is probably cryptographically less secure than the random token (assuming it using a random "swiss" number of sufficient length). However, most username/password authentication mechanisms will lock out the user after several wrong attempts. The cryptographic token doesn't do this, allowing for online, rather than off-line brute force attacks. We may conclude that this doesn't really matter. Further, we may ask: is it acceptable that mere possession of the token is sufficient to access the session? Many token-based authentication mechanisms also provide for a PIN or "something you know", to prevent accidental loss or theft of a physical item compromising everything. If we want this facility to comply with our security standards, then you will have to add this mechanism to your capability - maybe the session capability merely gives you a capability to enter a PIN, which if correct (say 3 guesses allowed), will unlock the session. So we can still use a capability mechanism - but note that we are designing an authentication mechanism.
All of this security analysis is done on the basis that what is being provided is an authentication process The underlying mechanism is irrelevant to the consideration of the risks and how it will be viewed in any real-world implementation.
Well, you are always just a process to the computer! One that represents you. The point of authentication is to prove your (the process that represents you) right to use a user-account to the computer in a way that only you could. This could be a secret (something you know), a token (something you have), or a biometric (something you are). Identity is definitely a slippery concept when you get down to it, but it's not a useless one. Of course, your slashdot password and username doesn't really identify *you*... but you're not going to post them on here are you?
As far as cloned processes go, you have to trust that the computer won't actively try to subvert its own security processes; this is the trusted computing base. If you don't have trust in the TCB, then as you say, it's game over. Of course, why you would want to authenticate to a machine you didn't trust at all is beyond me...
I don't understand your point about authorisation being "easily forged" - if authorisation could be easily forged, it wouldn't be a very good mechanism! A capability is the binding of a permission to do something to the designation of an object: designation + action = capability. However, I'm afraid that I don't understand how concatenating a machine address, questions and responses forms a location, nor what the action you mention is.
That is a more interesting thought experiment. I would say the user authenticates to the system using the token - something the user has. The purpose is only to (indirectly) identify the user (as opposed to any other user), to allow them to keep using their session.
Having said that, you are using a capability authorization mechanism to perform authentication. Which demonstrates how flexible and useful this mechanism is - but I still say the process looks like authentication, and behaves like authentication, therefore...
The example does blur the line quite nicely though. Thanks for posting it.
I will concede that "managing permissions bound to an identity" isn't a great definition. The permissions themselves don't need to be bound to an identity, as capability systems demonstrate very well. A better definition might be "managing the association of permissions with an identity". Taking a very granular view, in an object based capability model, each object has an identity. Regardless of how they are bound, would you agree that authorization is about moving permissions around things that have identities.
Well, as I've said above, I know capability based access control very well. I nearly did my MSc degree dissertation on it, specifically the work of Mark Miller on the E language and distributed capabilities. But your original statement about authentication is still wrong. You still need good authentication in a capability based system. Authentication and authorization are not alternatives to one another!
I know the work of Mark Miller, Jonathon Shapiro, the E language, Waterken, etc. very well. It's really good stuff, and it has the potential to make more secure systems. However, I'm sorry to say, you've become a "true believer" and this is leading you into making vastly overreaching statements.
Authentication is not a broken concept. Authentication refers to the act of *proving* a claimed identity. Regardless of the authorization model that follows, you have to authenticate at the beginning. Doesn't matter if it's capabilities, access control lists, mandatory access control, whatever. You start with authentication.
Even in capability-based security, you need strong authentication. Or someone could just log-in as you (the authentication bit) and use your capabilities.
It is true that capabilities bind a permission to an object, so knowledge of the subject by the system is not required to use a capability. This has certain benefits - it's performant, it allows easy delegation or permissions to other subjects, and it avoids the Confused Deputy problem. There are also some downsides to this form of access control - it's hard to contain the spread of permissions outside of a trusted computing base, and it's harder (but not impossible) to revoke permissions once granted.
But this has nothing to do with authentication! You still need it in a capability based system!
"No. If you mandate long passwords on the server, there are no short passwords. That's sort of the point."
He doesn't say there's a mixture of short and long passwords. He's saying that with long passwords, the attackers only get a few of them, not all of them. But they attackers only need a few of them. So long passwords (set on the server or wherever!) don't help as much as you'd like to think. In that specific threat scenario, anyway.
"to try and hide his introduction of the meme that an anti-virus program that doesn't really work is still a "really good thing"(TM)."
He ends by saying that there are better things to spend money on that more anti-virus. I don't know where you're getting it from.
Very well put. Much of religion makes a lot more sense once you understand what the underlying intention is. What's so sad is that the original authors were making as many good points in as many ways as they could. And we get centuries of small minded people taking it all literally and missing the point spectacularly.
That's funny:) In my experience, it's the Windows users who have loads of warez installed on their machines. Usually at least photoshop, office and winzip (did anyone ever pay for that?).
The disk is always encrypted. It's decrypted on the fly, transparently to the O/S, when running. You're right that leaving it in sleep mode is a bit more vulnerable than leaving it powered off - if people can get around your windows lock without powering off, game over.
How can they own ideas? Copyright law covers specific expressions of an idea - and is automatic. Patent law covers specific methods of achieving something - and must be applied for. I don't know of any law that allows automatic "ownership" of ideas. Can you clarify why you say they technically own your idea?
I doubt there's a document you could present without freaking their legal team out. If they decide to give the code away, they will want to be sure there are no legal repercussions, and decide on exactly what terms. Bottom line - he can ask them to do it, but should not try to do their lawyering for them. It's their legal risk, not his.
I did something similar a few years ago, for a company I felt equally warm about. I hope you have got all of that in writing though.
When our little company got merged into a bigger one, their lawyers tried to take my code. I pointed out my modified contract, and told them no way! They came back and said they would keep using my code, but only if I accepted liability for their use of it. I told them they were still welcome to continue using my code, but at their own risk, or, of course, they were free to strip it out entirely if they weren't happy. If they hadn't agreed at that point, I was going to request full commercial licensing fees from them (they had been using it for free up to that point, and I had sold commercial licenses to many other firms). They agreed:)
Anyway, moral of the story is that no matter how good your relations with the company, you can't guarantee you will always be dealing with the same people, so get it in writing!
A recent Danish study into conversion between ODF, DOC and OOXML concluded that MS Office was the best at dealing with all of those formats. So Microsoft need have no real fears that people will leave Office immediately if ODF was widely adopted.
But it still makes sense that Microsoft are unhappy with ODF and want to push OOXML. ODF is controlled by OASIS, and would allow much greater competition in the office software market. In the medium to long term, the Office software monopoly could be broken - if they failed to innovate and compete, that is.
I think people are getting confused by the idea of revocability. It says that the versions Sun participates in are freely implementable by anyone without fear of patent reprisal. Even if Sun drops out of future versions, those earlier versions are still freely implementable. It appears to be a condition of contributing to the OASIS standards process - otherwise you could just make sure your patented technology was included in a standard, then just drop out of the process and sue everyone.
If Sun do wish to cease participating in future versions of ODF, then they can use their patents against implementors of those future versions. It's not clear to me whether this means only against any new features introduced - I assume this must be the case, but IANAL.
Absolutely true - if OOXML is truly open, it won't hurt IBM consulting a bit. In fact, having two open document standards would almost certainly bring more revenue for them.
Slashdot Mirror
That may be true in some cases, but in this case, they are not defending against traffic analysis, which requires the ISP to maintain state about lots of data flows and analyse it in near-real time. If you look at what the BitTorrent devs are doing, they are obfuscating the peer list in the protocol, to prevent packet inspection from identifying the connection as BitTorrent. Interestingly, they are also intentionally using weak crypto (for performance reasons) - the goal being simply to raise the detection bar, not to create a cryptographically secure protocol.
Sooo.... you're quite happy that useful models can be built that make predictions about human intentions. But you don't think it works with the climate, because those dang scientists keep adjusting their models until they give predictions that fit. And the difference between these two is...?
Freudian slips! "but I would assert that it is being used as part of an authorization process, which is how the security it provides would be judged." and "The system gives two "authorization" paths"
I meant to say "an authentication process" and "authentication paths"!
Well, we're clearly coming from different perspectives on this one. I don't deny that it *is* a capability - but I would assert that it is being used as part of an authorization process, which is how the security it provides would be judged.
In terms of a security risk analysis of this system, I would want to know the strength of protection that this system allows for its users and the content being protected. The system gives two "authorization" paths to access the resources of a user: (1) log in with a password (2) use the USB key to recover a session. From my perspective, I don't care about the underlying mechanisms - I want to know that all the paths meet a minimum security standard.
Taking this experiment a bit further: the username / password combination is probably cryptographically less secure than the random token (assuming it using a random "swiss" number of sufficient length). However, most username/password authentication mechanisms will lock out the user after several wrong attempts. The cryptographic token doesn't do this, allowing for online, rather than off-line brute force attacks. We may conclude that this doesn't really matter. Further, we may ask: is it acceptable that mere possession of the token is sufficient to access the session? Many token-based authentication mechanisms also provide for a PIN or "something you know", to prevent accidental loss or theft of a physical item compromising everything. If we want this facility to comply with our security standards, then you will have to add this mechanism to your capability - maybe the session capability merely gives you a capability to enter a PIN, which if correct (say 3 guesses allowed), will unlock the session. So we can still use a capability mechanism - but note that we are designing an authentication mechanism.
All of this security analysis is done on the basis that what is being provided is an authentication process The underlying mechanism is irrelevant to the consideration of the risks and how it will be viewed in any real-world implementation.
Well, you are always just a process to the computer! One that represents you. The point of authentication is to prove your (the process that represents you) right to use a user-account to the computer in a way that only you could. This could be a secret (something you know), a token (something you have), or a biometric (something you are). Identity is definitely a slippery concept when you get down to it, but it's not a useless one. Of course, your slashdot password and username doesn't really identify *you*... but you're not going to post them on here are you?
As far as cloned processes go, you have to trust that the computer won't actively try to subvert its own security processes; this is the trusted computing base. If you don't have trust in the TCB, then as you say, it's game over. Of course, why you would want to authenticate to a machine you didn't trust at all is beyond me...
I don't understand your point about authorisation being "easily forged" - if authorisation could be easily forged, it wouldn't be a very good mechanism! A capability is the binding of a permission to do something to the designation of an object: designation + action = capability. However, I'm afraid that I don't understand how concatenating a machine address, questions and responses forms a location, nor what the action you mention is.
That is a more interesting thought experiment. I would say the user authenticates to the system using the token - something the user has. The purpose is only to (indirectly) identify the user (as opposed to any other user), to allow them to keep using their session.
Having said that, you are using a capability authorization mechanism to perform authentication. Which demonstrates how flexible and useful this mechanism is - but I still say the process looks like authentication, and behaves like authentication, therefore...
The example does blur the line quite nicely though. Thanks for posting it.
I will concede that "managing permissions bound to an identity" isn't a great definition. The permissions themselves don't need to be bound to an identity, as capability systems demonstrate very well. A better definition might be "managing the association of permissions with an identity". Taking a very granular view, in an object based capability model, each object has an identity. Regardless of how they are bound, would you agree that authorization is about moving permissions around things that have identities.
Well, as I've said above, I know capability based access control very well. I nearly did my MSc degree dissertation on it, specifically the work of Mark Miller on the E language and distributed capabilities. But your original statement about authentication is still wrong. You still need good authentication in a capability based system. Authentication and authorization are not alternatives to one another!
I know the work of Mark Miller, Jonathon Shapiro, the E language, Waterken, etc. very well. It's really good stuff, and it has the potential to make more secure systems. However, I'm sorry to say, you've become a "true believer" and this is leading you into making vastly overreaching statements.
Authentication is not a broken concept. Authentication refers to the act of *proving* a claimed identity. Regardless of the authorization model that follows, you have to authenticate at the beginning. Doesn't matter if it's capabilities, access control lists, mandatory access control, whatever. You start with authentication.
Even in capability-based security, you need strong authentication. Or someone could just log-in as you (the authentication bit) and use your capabilities.
It is true that capabilities bind a permission to an object, so knowledge of the subject by the system is not required to use a capability. This has certain benefits - it's performant, it allows easy delegation or permissions to other subjects, and it avoids the Confused Deputy problem. There are also some downsides to this form of access control - it's hard to contain the spread of permissions outside of a trusted computing base, and it's harder (but not impossible) to revoke permissions once granted.
But this has nothing to do with authentication! You still need it in a capability based system!
You think authentication is a "broken concept"?
Authentication - providing proof of a claimed identity
Authorization - managing permissions bound to an identity
See why you need both? You clearly have no idea what you're talking about, whoever you are.
"No. If you mandate long passwords on the server, there are no short passwords. That's sort of the point."
He doesn't say there's a mixture of short and long passwords. He's saying that with long passwords, the attackers only get a few of them, not all of them. But they attackers only need a few of them. So long passwords (set on the server or wherever!) don't help as much as you'd like to think. In that specific threat scenario, anyway.
"to try and hide his introduction of the meme that an anti-virus program that doesn't really work is still a "really good thing"(TM)."
He ends by saying that there are better things to spend money on that more anti-virus. I don't know where you're getting it from.
I can't see anything in the article that suggests he's saying that. And I don't see him pushing a product either.
Very well put. Much of religion makes a lot more sense once you understand what the underlying intention is. What's so sad is that the original authors were making as many good points in as many ways as they could. And we get centuries of small minded people taking it all literally and missing the point spectacularly.
That's funny :) In my experience, it's the Windows users who have loads of warez installed on their machines. Usually at least photoshop, office and winzip (did anyone ever pay for that?).
The disk is always encrypted. It's decrypted on the fly, transparently to the O/S, when running. You're right that leaving it in sleep mode is a bit more vulnerable than leaving it powered off - if people can get around your windows lock without powering off, game over.
Why do you say DriveLock has no performance penalty? It does software encryption, same as TrueCrypt.
How can they own ideas? Copyright law covers specific expressions of an idea - and is automatic. Patent law covers specific methods of achieving something - and must be applied for. I don't know of any law that allows automatic "ownership" of ideas. Can you clarify why you say they technically own your idea?
I doubt there's a document you could present without freaking their legal team out. If they decide to give the code away, they will want to be sure there are no legal repercussions, and decide on exactly what terms. Bottom line - he can ask them to do it, but should not try to do their lawyering for them. It's their legal risk, not his.
I was about to post the same.
I did something similar a few years ago, for a company I felt equally warm about. I hope you have got all of that in writing though.
:)
When our little company got merged into a bigger one, their lawyers tried to take my code. I pointed out my modified contract, and told them no way! They came back and said they would keep using my code, but only if I accepted liability for their use of it. I told them they were still welcome to continue using my code, but at their own risk, or, of course, they were free to strip it out entirely if they weren't happy. If they hadn't agreed at that point, I was going to request full commercial licensing fees from them (they had been using it for free up to that point, and I had sold commercial licenses to many other firms). They agreed
Anyway, moral of the story is that no matter how good your relations with the company, you can't guarantee you will always be dealing with the same people, so get it in writing!
A recent Danish study into conversion between ODF, DOC and OOXML concluded that MS Office was the best at dealing with all of those formats. So Microsoft need have no real fears that people will leave Office immediately if ODF was widely adopted.
http://dokumentformater.oio.dk/
But it still makes sense that Microsoft are unhappy with ODF and want to push OOXML. ODF is controlled by OASIS, and would allow much greater competition in the office software market. In the medium to long term, the Office software monopoly could be broken - if they failed to innovate and compete, that is.
Wow - so Microsoft's office division *spend* $1.6 billion each quarter on Office? $6 billion a year? Just, wow.
I think people are getting confused by the idea of revocability. It says that the versions Sun participates in are freely implementable by anyone without fear of patent reprisal. Even if Sun drops out of future versions, those earlier versions are still freely implementable. It appears to be a condition of contributing to the OASIS standards process - otherwise you could just make sure your patented technology was included in a standard, then just drop out of the process and sue everyone.
If Sun do wish to cease participating in future versions of ODF, then they can use their patents against implementors of those future versions. It's not clear to me whether this means only against any new features introduced - I assume this must be the case, but IANAL.
Absolutely true - if OOXML is truly open, it won't hurt IBM consulting a bit. In fact, having two open document standards would almost certainly bring more revenue for them.