From: "Tyler Close" <tyler@...>
>
> On Friday 02 May 2003 14:36, Seairth Jacobs wrote:
> > Why is the recipient forced to access the resource?  The decision to
access
> > the resource is 100% under the control of the recipient (and recipient's
> > application).  No external source can force the resource to be
retrieved.
> > It is certainly possible that a recipient could carelessly believe a
> > legitimate notification, but I'm not aware of *any* security model that
can
> > stop a recipient from being careless.
>
> The problem is that the ACL model makes it very difficult to not
> be careless with your authority.
>
> Assume the recipient has the authority to read a large number of
> resources on some server. Further assume that the recipient does
> not want his own credentials to be associated with a request to
> some of those resources. If the recipient makes a request using a
> URL taken from a notification, then the producer of the
> notification is deciding which resource the receiver will access.
> The receiver has delegated control over his ability to make
> requests to the notification producer.

Okay.  I agree with this.

> The problem is that the receiver is making the request using the
> URL specified by the attacker and the receiver's own credentials.
>
> This type of attack is not possible in a capability-based design
> because the resource identifier and the authority to access the
> resource are bound together. If the notification delivered a
> capability URL, then the receiver would access the resource using
> the credentials provided by the notification producer, and not the
> receiver's credentials. In this case, the resource request would
> be associated with the notification producer, not the recipient.

But this *is* the scenario right now, if I understand you correctly.  The
recipient receives a notification that looks like:

<notification>
     <from uri="http://seairth.com/rna">
     <resource uri="http://user:pwd@seairth.com/rna/msg/1234" />
</notification>

The recipient is using only credentials given to him via the notification.
Any person in the world could, given knowledge of the value of the "uri"
attribute, access the resource.  At the same time, it would be possible for
a sender to use the same user/pwd for several recipients.  However, this is
up to the discretion of the creator of the resource (who may or may not be
the same as the sender of the notification).  From the client's perspective,
all of this is opaque.

Also, the reason I suggest using user/pwd instead of a random, unguessable
token in the URI is because I think the user/pwd is more in line with the
REST philosophy.  This ensures that a single uri (sans the "user:pwd@ part")
identifies the same representation of the resource regardless of which
authentication credentials are provided, which is important for things like
caching proxies, etc...

As I understand it, the sender has a resource he want's to make available to
a recipient.  The sender assigns a capability (URI + user/pwd,  in this
case) and gives it to the recipient.  Now, maybe I am not understanding the
subtleties of a "capability URI".  If I have got it wrong, can you given an
example (possibly in context of RNA) that would make the difference more
clear?

> The attack is not so much targeted at RNA, as it is at how RNA is
> used. In the previous emails, you were indicating that the RNA
> client would provide a stored username/password in a request for a
> received notification URL. Doing this opens you up to a Confused
> Deputy attack.

I think there may be some miscommunication here (on my part).  Those
statements were made with the assumption that the examples at
http://www.seairth.com/web/rna were read.  Any stored user/password pairs
were provided by the sender of the notification, not by the recipient.  I
had meant "stored" only in terms of the user/password that was kept by the
recipient from the notification.

>
> I think I've explained things more clearly this time. Do you
> understand now?

This conversation has certainly helped.  Thank you.  I do have some
questions, however.  I believe that the above approach effectively uses
capabilities, but I still do not understand how any additional protection
can be afforded to the sender than there already is by using capabilities.
When I went and looked up information on the Confused Deputy attack, I did
not see how it applied to this situation.  If you still see problems what
capabilities was applied wrong, please let me know.

---
Seairth Jacobs
seairth@...

On Friday 02 May 2003 14:36, Seairth Jacobs wrote:
> Why is the recipient forced to access the resource?  The decision to access
> the resource is 100% under the control of the recipient (and recipient's
> application).  No external source can force the resource to be retrieved.
> It is certainly possible that a recipient could carelessly believe a
> legitimate notification, but I'm not aware of *any* security model that can
> stop a recipient from being careless.

The problem is that the ACL model makes it very difficult to not
be careless with your authority.

Assume the recipient has the authority to read a large number of
resources on some server. Further assume that the recipient does
not want his own credentials to be associated with a request to
some of those resources. If the recipient makes a request using a
URL taken from a notification, then the producer of the
notification is deciding which resource the receiver will access.
The receiver has delegated control over his ability to make
requests to the notification producer.

The problem is that the receiver is making the request using the
URL specified by the attacker and the receiver's own credentials.

This type of attack is not possible in a capability-based design
because the resource identifier and the authority to access the
resource are bound together. If the notification delivered a
capability URL, then the receiver would access the resource using
the credentials provided by the notification producer, and not the
receiver's credentials. In this case, the resource request would
be associated with the notification producer, not the recipient.

The attack is not so much targeted at RNA, as it is at how RNA is
used. In the previous emails, you were indicating that the RNA
client would provide a stored username/password in a request for a
received notification URL. Doing this opens you up to a Confused
Deputy attack.

I think I've explained things more clearly this time. Do you
understand now?

Tyler

From: "Tyler Close" <tyler@...>
>
> On Friday 02 May 2003 12:06, Seairth Jacobs wrote:
> >
> > 1) Since there is a mechanism to ensure that the claimed sender of a
> > notification is the *actual* sender, an attacker cannot use
impersonation
> > (unless capable of Man In The Middle attacks) to send a bogus
notification.
>
> This claim is false.

Okay.  I don't see why, but I'm willing to be shown that I am wrong.

> > 2) If the recipient has a valid user/password for the given resource and
> > accesses it, then this would be a valid recording of
"message-read-by-XXX"
> > regardless of who sent the notification.
>
> I assume that if a recipient decides that he does not want to
> register a "message-read-by-XXX" for a particular resource, then
> it should be impossible to force him to. Your ACL design does not
> provide the recipient with this level of control.

Why is the recipient forced to access the resource?  The decision to access
the resource is 100% under the control of the recipient (and recipient's
application).  No external source can force the resource to be retrieved.
It is certainly possible that a recipient could carelessly believe a
legitimate notification, but I'm not aware of *any* security model that can
stop a recipient from being careless.

> For example, assume there is a resource at
>
> http://www.yahoo.com/rna/msg/1234
>
> The resource is a child porn picture.  Recipient Bob does not want
> to register a "message-read-by-XXX" for resource 1234.
>
> The attacker sends Bob a notification:
>
> <rna:notification xmlns:rna="http://purl.org/rna/1.0/">
>     <rna:from uri="http://www.yahoo.com/rna" />
>     <rna:subject>Cute kitties</rna:subject>
>     <rna:resource uri="http://www.yahoo.com/rna/msg/1234" />
> </rna:notification>
>
> Bob verifies the notification by sending a Query to www.yahoo.com:

Actually, bob would send the query to http://www.yahoo.com/rna, or more
generically to the claimed "from" URI.

> <rna:query xmlns:rna="http://purl.org/rna/1.0/">
>     <rna:to uri="http://myrna.com/users/bob" />
>     <rna:resource uri="http://www.yahoo.com/rna/msg/1234" />
> </rna:query>
>
> The yahoo.com server verifies the query using Bob's
> username/password, provided via HTTP Auth. Bob's yahoo account is
> valid and he is authorized to access the resource. The access is
> recorded.

No, the query is asking the sender if he did send a notification about the
given resource to bob.  That's all.  As long as the claimed sender has
control over his URI, he is authoritative as to whether he sent a
notification or not.  At the same time, the response to the query is the
"original" notification.  This allows the recipient to make sure that the
notification was not tampered with (such as might be used in a Replay
attack) and also disallows the sender from making a bogus claim of sending a
notification that he did not send.

Now, there are going to be a few changes to the query mechanism, but I
believe the fundamental process will not change... more on that later.

> Bob gets back the authenticated notification. The authenticated
> notification is the same as the original.
>
> Bob then gets the resource, whose representation is suprising and
> unwanted. FBI comes knocking at Bob's door.

But this can happen for a legitimate notification as well.  I don't see how
any form of security ensure that the resource is "safe" to open.  I feel
that the FBI comment is unfounded here.  All it serves to do is draw
attention away from the credibility of the rest of the arguement, which I
don't buy into (yet).  Further, the FBI would also have the URI of the
source, the "from" URI, and possibly the notification URI, all of which
would point to the actual culprit (as much as any URI can do that).

> As I said in the last post, this type of attack is endemic to ACL
> designs. RNA doesn't do all that much yet, so this attack is just
> the tip of the iceberg. As you add more functionality, there will
> be more Confused Deputy attacks. This class of attacks is not
> possible in a capability-based design.

I will certainly have to study the capability-based design.  However, I do
not believe that RNA is explicitly using an ACL design.  I agree that such a
design could be supported, but I don't think that RNA forces this viewpoint
on anyone.

It seems to me, though, that I have not clearly explained the query
mechanism at this point...  I will need to work on that.

---
Seairth Jacobs
seairth@...

Tyler Close wrote:

>I assume that if a recipient decides that he does not want to
>register a "message-read-by-XXX" for a particular resource, then
>it should be impossible to force him to. Your ACL design does not
>provide the recipient with this level of control.
>
>For example, assume there is a resource at
>
>http://www.yahoo.com/rna/msg/1234
>
>The resource is a child porn picture.  Recipient Bob does not want
>to register a "message-read-by-XXX" for resource 1234.
>
>The attacker sends Bob a notification:
>
><rna:notification xmlns:rna="http://purl.org/rna/1.0/">
>    <rna:from uri="http://www.yahoo.com/rna" />
>    <rna:subject>Cute kitties</rna:subject>
>    <rna:resource uri="http://www.yahoo.com/rna/msg/1234" />
></rna:notification>
>
>Bob verifies the notification by sending a Query to www.yahoo.com:
>
><rna:query xmlns:rna="http://purl.org/rna/1.0/">
>    <rna:to uri="http://myrna.com/users/bob" />
>    <rna:resource uri="http://www.yahoo.com/rna/msg/1234" />
></rna:query>
>
>The yahoo.com server verifies the query using Bob's
>username/password, provided via HTTP Auth. Bob's yahoo account is
>valid and he is authorized to access the resource. The access is
>recorded.
>
>Bob gets back the authenticated notification. The authenticated
>notification is the same as the original.
>
>Bob then gets the resource, whose representation is suprising and
>unwanted. FBI comes knocking at Bob's door.
>
>

I think I've missed something here.  It seems to me that all you've done
is tricked Bob into thinking he wants to access the resource by
providing a misleading subject line.

Maybe I missed an implicit assumption when you said that Bob doesnt want
to access
http://www.yahoo.com/rna/msg/1234.  How did he make that decision and
why is he not able to come to the same conclusion in this situation?

--Chuck

On Friday 02 May 2003 12:42, Tyler Close wrote:
> The yahoo.com server verifies the query using Bob's
> username/password, provided via HTTP Auth. Bob's yahoo account is
> valid and he is authorized to access the resource. The access is
> recorded.

I think I guessed the wrong place in your protocol for the access
control check. It looks like the check takes place later. Either
way, the recipient is being forced to fetch a resource specified
by someone else using the recipient's own credentials.

Tyler

On Friday 02 May 2003 12:06, Seairth Jacobs wrote:
> If, on the other hand, you are assuming that the notification from the
> attacker to the recipient does not contain the user/password and that the
> recipient will attempt to use a stored user/password,

Yes, this is the case I am considering.

> then I have two responses:
>
> 1) Since there is a mechanism to ensure that the claimed sender of a
> notification is the *actual* sender, an attacker cannot use impersonation
> (unless capable of Man In The Middle attacks) to send a bogus notification.

This claim is false.

> 2) If the recipient has a valid user/password for the given resource and
> accesses it, then this would be a valid recording of "message-read-by-XXX"
> regardless of who sent the notification.

I assume that if a recipient decides that he does not want to
register a "message-read-by-XXX" for a particular resource, then
it should be impossible to force him to. Your ACL design does not
provide the recipient with this level of control.

For example, assume there is a resource at

http://www.yahoo.com/rna/msg/1234

The resource is a child porn picture.  Recipient Bob does not want
to register a "message-read-by-XXX" for resource 1234.

The attacker sends Bob a notification:

<rna:notification xmlns:rna="http://purl.org/rna/1.0/">
     <rna:from uri="http://www.yahoo.com/rna" />
     <rna:subject>Cute kitties</rna:subject>
     <rna:resource uri="http://www.yahoo.com/rna/msg/1234" />
</rna:notification>

Bob verifies the notification by sending a Query to www.yahoo.com:

<rna:query xmlns:rna="http://purl.org/rna/1.0/">
     <rna:to uri="http://myrna.com/users/bob" />
     <rna:resource uri="http://www.yahoo.com/rna/msg/1234" />
</rna:query>

The yahoo.com server verifies the query using Bob's
username/password, provided via HTTP Auth. Bob's yahoo account is
valid and he is authorized to access the resource. The access is
recorded.

Bob gets back the authenticated notification. The authenticated
notification is the same as the original.

Bob then gets the resource, whose representation is suprising and
unwanted. FBI comes knocking at Bob's door.

As I said in the last post, this type of attack is endemic to ACL
designs. RNA doesn't do all that much yet, so this attack is just
the tip of the iceberg. As you add more functionality, there will
be more Confused Deputy attacks. This class of attacks is not
possible in a capability-based design.

> Now, maybe I am missing something, but this seems like a weak (at best)
> attack given the way that RNA is currently designed.  If I have missed some
> point(s), please share them.  I certainly do not want RNA to be incapable
> of supporting a solid security model...

Compare this statement with your earlier statement that you don't
want to build in a security model. Do you see the tension between
these two statements?

Tyler

From: "Tyler Close" <tyler@...>
>
> On Friday 02 May 2003 10:01, Seairth Jacobs wrote:
> > An RNA client would probably go through the following routine to
discover
> > the correct password for an old resource:
> >
> > 1) Use user/password of associated notification. If authentication
fails,
> > 2) Use most recent user/password sent by particular sender.
>
> One of the features you are aiming for with RNA, is notification
> that a recipient has read a message. You intend to support this
> feature by recording that the recipient has requested a resource
> representation.
>
> If you use user/password authentication, the "message-read"
> notification can be easily subverted by an attacker. Since you are
> using guessable URLs, the attacker simply has to send the
> recipient a URL notification. The recipient will then request a
> resource representation using the given URL and its user/password.
> In this way, the attacker can trick the recipient into registering
> a "message-read" notification for any URL.
>
> This attack is an example of a Confused Deputy attack. Confused
> Deputy attacks are endemic to ACL designs. A capability based
> design is not vulnerable to a Confused Deputy attack.

There seem to be two parts to this:

1) An anonymous access of the resource.  In this case, "message-read" is all
that's necessary.
2) An authorized access of the resource.  In this case, you can have either
"message-read" or "message-read-by-XXX".  It seems to me that the only thing
an attacker could do here would be to send a notification for a known
URI+user+password to a recipient who is not associated by the controller of
the resource to that resource.  In this case, the recipient would appear to
be whoever *was* associated.  In this case "message-read" would still be
valid, but "message-read-by-XXX" would not.

However, If an attacker already knows the URI+user+password of a resource,
why bother with the Confused Deputy attack?

If, on the other hand, you are assuming that the notification from the
attacker to the recipient does not contain the user/password and that the
recipient will attempt to use a stored user/password, then I have two
responses:

1) Since there is a mechanism to ensure that the claimed sender of a
notification is the *actual* sender, an attacker cannot use impersonation
(unless capable of Man In The Middle attacks) to send a bogus notification.

2) If the recipient has a valid user/password for the given resource and
accesses it, then this would be a valid recording of "message-read-by-XXX"
regardless of who sent the notification.


Now, maybe I am missing something, but this seems like a weak (at best)
attack given the way that RNA is currently designed.  If I have missed some
point(s), please share them.  I certainly do not want RNA to be incapable of
supporting a solid security model...

---
Seairth Jacobs
seairth@...

On Friday 02 May 2003 10:01, Seairth Jacobs wrote:
> An RNA client would probably go through the following routine to discover
> the correct password for an old resource:
>
> 1) Use user/password of associated notification. If authentication fails,
> 2) Use most recent user/password sent by particular sender.

One of the features you are aiming for with RNA, is notification
that a recipient has read a message. You intend to support this
feature by recording that the recipient has requested a resource
representation.

If you use user/password authentication, the "message-read"
notification can be easily subverted by an attacker. Since you are
using guessable URLs, the attacker simply has to send the
recipient a URL notification. The recipient will then request a
resource representation using the given URL and its user/password.
In this way, the attacker can trick the recipient into registering
a "message-read" notification for any URL.

This attack is an example of a Confused Deputy attack. Confused
Deputy attacks are endemic to ACL designs. A capability based
design is not vulnerable to a Confused Deputy attack.

Tyler

On Friday 02 May 2003 02:28, Michael Day wrote:
> I think the discussion would benefit from your input on security issues,

Thank you.

> particularly if you have some ideas in mind on security models that could
> be applied to RNA.

I do have some ideas. I hope you will give them due hearing and
not jump to premature and uninformed decisions.

> Would it be possible for you to summarise what you mean by security model
> and how it would affect the architecture?

Well, the first step is to develop a thread model. This is just a
list of the different types of attackers, what powers each has,
and what each attacker would like to do.

For example, in your most recent "five methods" draft:

On Friday 02 May 2003 02:38, Michael Day wrote:
> Note that methods 3 and 4 are similar in that anyone who gets hold of the
> URL can access the resource, however user/password authentication tokens
> can be used with HTTP Digest authentication, while generated URLs will be
> sent as plain text unless HTTP over SSL is used.

In this paragraph, you are assuming an attacker who has the power
to eavesdrop on communications and wants to get a copy of the
resource representation.

You argue that since a URL containing a generated secret can be
eavesdropped, it is less secure than user/password authentication.
However, if the attacker has the ability to eavesdrop, then for
either mechanism, he can just wait until the server sends the
resource representation, and read it directly off the wire.
There's no need to get either the secret URL or the user/password.

If you had built a threat model, you no doubt would have
discovered this logical flaw on your own.

I suggest you develop several use-cases for RNA and then decide
what types of attackers you wish to defend against. Otherwise, you
are just wasting your time.

Tyler

From: "Michael Day" <mikeday@...>
>
> There are five methods of authentication:
>
>  3. Randomly generated user/password. This is sent to the recipient to be
>     used as an authentication token, probably for one message only.

However, a recipient should not make any such assumption about the
uniqueness of the user/password combination.  A system may choose to
maintain a single user/password combination for a given recipient, re-using
the same user/password pair for all notifications sent to that recipient.
This approach has both advantages and disadvantages:

Advantages:
1) Ease of maintenance.
2) If recipient needs to access resource via browser (or other non-rna
client), committing a single user/password to memory is much easier.
3) Discourages a recipient from sharing access to the resource because they
are then potentially sharing access to other resources they don't intend to
share.

Disadvantages:
1) If an unauthorized person gains knowledge of the user/password, the
person may be able to gain access to other resources as well.
2) Generation of a new pair of user/password (or likely just password)
values  would potentially change the access for all existing resources.  A
simple solution would be that  if the password is changed, then sending a
new notification about the change would effectively give the new password.

An RNA client would probably go through the following routine to discover
the correct password for an old resource:

1) Use user/password of associated notification. If authentication fails,
2) Use most recent user/password sent by particular sender.

>  5. Public Key Infrastructure. I don't know much about this, but it seems
>     to be the only way of ensuring the person retrieving the message is
the
>     person that the message is sent to, based on their public key.

Here are is how PKI can help:

1) Validation of notification (avoids need for RNA query).  In this case,
the sender "signs" the notification by encrypting some portion with his
private key, then sends both the encrypted string and the original data in
the notification.  The recipient then decrypts the string using the senders
public key and compares the two values.  If they match, then the signature
is valid.  If they don't match, it means the notification is invalid (due to
tampering, impersonation, etc.).  Note that this approach requires a certain
amount of normalization of the notification contents to ensure proper
round-tripping.  For instance, the entire notification would have to be
exactly the same (octet-wise) for both encryption and decryption).  As a
result, elements must be in a fixed order, character entities must be
normalized, attributes must be in the same order, etc.)   Also, if an
application is going to allow intermediaries to add elements, a provision
would have to be made to avoid including those elements in the normalized
version (unless they too need to be signed and verified, which is just that
much more complicated).

2) Authentication for access to resource.  In this case, the resource would
be encrypted with the recipient's public key and returned to the recipient,
who would then have to have the correct private key to decrypt.  However,
this would still require the recipient to identify themselves when getting
the resource.  For instance, the recipient might have to issue something
like (properly escaped):

     GET /resource/123?to=http://seairth.com/rna

One of the biggest problems with PKI (to my knowledge) is the expense of
maintaining the infrastructure.  In order for PKI to work, someone must be a
trusted repository of the public keys.  If you have ever looked at the
prices that RSA/Verisign charges for their keys (depending on the strength
you want), you will see why it is cost prohibitive that the majority of
users out there.  Now, I admit that people do not necessarily take security
seriously enough, but that's another issue.

While I think support for PKI in RNA would be a Good Thing, I think it
should be *a* security model, not *the* security model.  (I'm not sure that
anyone is arguing this point. I just wanted to be clear about what my
thoughts are on this.)

>  4. Randomly generated URL id. The URL sent to the recipients includes a
>     randomly generated authentication token.
>
> (Generating URLs containing authentication tokens seems like a Bad Idea).

I agree!  Even if the resource is intended for a single recipient, you will
still have two authentication tokens: one for the recipient and one for
yourself.

---
Seairth Jacobs
seairth@...

I've rewritten this message based on Tyler's comments on incorrect
aphorisms.

There are five methods of authentication:

  1. No authentication. Useful for public messages, mailing lists and so
     on, or for local messaging on one system or network behind a firewall.

  2. Persistent user/password. Useful for when you are receiving messages
     from a server on which you already have an account of some kind.
     For example, corporate mail server, Microsoft passport (ugh), or some
     kind of ISP mail gateway.

  3. Randomly generated user/password. This is sent to the recipient to be
     used as an authentication token, probably for one message only.

  4. Randomly generated URL id. The URL sent to the recipients includes a
     randomly generated authentication token.

  5. Public Key Infrastructure. I don't know much about this, but it seems
     to be the only way of ensuring the person retrieving the message is the
     person that the message is sent to, based on their public key.

Note that methods 3 and 4 are similar in that anyone who gets hold of the
URL can access the resource, however user/password authentication tokens
can be used with HTTP Digest authentication, while generated URLs will be
sent as plain text unless HTTP over SSL is used.

Note also that different passwords could be sent to different recipients,
allowing the sender to know which of the recipients have accessed the
resource, while generating URLs would require multiple URLs per resource.

(Generating URLs containing authentication tokens seems like a Bad Idea).

Michael Day

YesLogic Pty. Ltd.

> I have to admit that I do find it very strange that this group is
> designing a communication protocol with no security model. Is the
> world really crying out for yet another insecure messaging
> protocol? Logically, it doesn't make sense to me to design an
> internet scale communication protocol without starting from a
> security model.

I think the discussion would benefit from your input on security issues,
particularly if you have some ideas in mind on security models that could
be applied to RNA.

Would it be possible for you to summarise what you mean by security model
and how it would affect the architecture?

Thanks,

Michael Day

YesLogic Pty. Ltd.

> The use of a randomly generated secret for authentication purposes
> has nothing to do with "security through obscurity". Use of a
> nonce in an authentication protocol is standard practice. I
> suggest you pick up a book on cryptographic protocols.

Thanks, I had never heard the word "nonce" used outside of Shakespeare :)
In that case, replace what I said about "security through obscurity" with
"security by use of a randomly generated authentication token", or nonce.

Michael Day

YesLogic Pty. Ltd.

> Why make a special case?  And why force PUSH to only send one
> notification at a time?  It seems like an arbitrary restriction that
> reduces the ways in which PUSH might be used.  For instance, what if I
> want to batch my PUSHes - seems like I have to incur a lot of overhead
> for what appears to be an arbitrary decision.

If you want to POST multiple notifications, you could always make multiple
POSTs of single notifications over a persistent HTTP/1.1 connection.

So, connection overhead at least should not be an issue. While if multiple
notifications can be POSTed at once, this would have an impact on the
meaning of response codes and the response body (eg. if one notification
is not accepted, but the rest are).

Michael Day

YesLogic Pty. Ltd.

From: "Tyler Close" <tyler@...>
tracks, and I thought you might want to know.
>
> I have to admit that I do find it very strange that this group is
> designing a communication protocol with no security model. Is the
> world really crying out for yet another insecure messaging
> protocol? Logically, it doesn't make sense to me to design an
> internet scale communication protocol without starting from a
> security model.

First, this is not a messaging protocol.  This is a notification protocal.
I think this is a very important distinction.  When you say "messaging", you
may mean "notifications", but "messaging" has so much more baggage attached
to it (imho) than it should (when being used to mean "notifications").

Second, the reason that there is not a "security model" is that I think this
should be layered on top of a simple, clean foundation.  The world tends to
have quite a variety of security requirements.  As a result, the basic
protocol should not force any one particular model upon all people.
Instead, I would like to see a variety of security capabilities provided
that people can choose from to suit their needs.  So, I would have to say
that I am *very* aware of the need for security, but I am not intent on
making it the base that all else is built on...

And no.  I am not a security expert, so I realize I may be entirely wrong
about all of this.

---
Seairth Jacobs
seairth@...

Tyler Close wrote:

>On Thursday 01 May 2003 12:54, Chuck Hinson wrote:
>
>
>>I guess a better term
>>for what I was thinking is security through obfuscation.
>>
>>
>
>That is also incorrect.
>
>"security through obfuscation" refers to a security mechanism with
>no theoretical backing. Typically, this means that the security
>mechanism is deliberately made hard to understand and/or is
>undocumented. The hope is that the attacker won't bother trying to
>figure out what is being done.
>
>
Which is exactly what I meant by security through obfuscation.  I'm not
sure what you mean when you say it is also incorrect.

>For example, for ciphers, it is a tenet that all the security
>should be in the key and that the algorithm should be public. In
>times gone by, some people believed that security could also be in
>the algorithm and that the algorithm should be kept secret.  This
>is an example of "security through obfuscation".
>
>
>When using a nonce for authentication, all of the security rests
>in the randomness of the nonce. There is strong theoretical
>backing for building an authentication mechanism on this.
>
>
None of which I dispute (so I'm confused as to why you're pointing it
out).  Perhaps I'm not doing a very good job at communicating [again :-(
].  What I said eariler was that

<quote>
(I'm still not completely comfortable with the idea of capability-based
security that uses really long, randomly generated URIs - seems too much
like security through obscurity)
</quote>

I did not intend to classify randomly generated URIs as security through
obscurity. I accept that its not, but that doesnt mean I'm comfortable
with the concept. Its something new to me and it'll take me a while to
get my arms around it and trust it.  I need to play with it and use it
to fully understand the implications and consequences before I'll be
comfortable with it.  Until then, (for reasons I wont attempt to explain
here) it will continue to 'feel' like security through obfuscation.

>
>
>>Along with all the other books I need to pick up that are more closely
>>related to the kind of work I do.  Maybe one day I'll be involved in a
>>project that has more stringent security requirements.  Unfortunatley,
>>until that time comes, I'm not likely to devote much more than a passing
>>interest to the subject (and as a result, continue to demonstrate my
>>ignorance).
>>
>>
>
>That's fine. I'm not trying to pick on you or anything. It's just
>that the whole authentication sub-thread had completely left the
>tracks, and I thought you might want to know.
>
>I have to admit that I do find it very strange that this group is
>designing a communication protocol with no security model. Is the
>world really crying out for yet another insecure messaging
>protocol? Logically, it doesn't make sense to me to design an
>internet scale communication protocol without starting from a
>security model.
>
>
Your interest is (apparently) in security, so of course it doesnt make
sense to you.

My interest (and others on this list) is understanding the implications
of REST as an architecture, how to build RESTful systems, what happens
to scalability when you depart from REST,  when to apply REST, and etc.
To help us learn, we often find it helpful to test our understanding by
trying to build things according to the architectural style.   As far as
I know, REST doesnt have much to say about security.  I agree that
security is an important facet for an internet scale communication
protocol.  However, as far as I know, REST doesnt have much to say about
security, so I'm just not interested in that facet right now.

--Chuck

On Thursday 01 May 2003 12:54, Chuck Hinson wrote:
> I guess a better term
> for what I was thinking is security through obfuscation.

That is also incorrect.

"security through obfuscation" refers to a security mechanism with
no theoretical backing. Typically, this means that the security
mechanism is deliberately made hard to understand and/or is
undocumented. The hope is that the attacker won't bother trying to
figure out what is being done.

For example, for ciphers, it is a tenet that all the security
should be in the key and that the algorithm should be public. In
times gone by, some people believed that security could also be in
the algorithm and that the algorithm should be kept secret. This
is an example of "security through obfuscation".

When using a nonce for authentication, all of the security rests
in the randomness of the nonce. There is strong theoretical
backing for building an authentication mechanism on this.

> Along with all the other books I need to pick up that are more closely
> related to the kind of work I do. Maybe one day I'll be involved in a
> project that has more stringent security requirements. Unfortunatley,
> until that time comes, I'm not likely to devote much more than a passing
> interest to the subject (and as a result, continue to demonstrate my
> ignorance).

That's fine. I'm not trying to pick on you or anything. It's just
that the whole authentication sub-thread had completely left the
tracks, and I thought you might want to know.

I have to admit that I do find it very strange that this group is
designing a communication protocol with no security model. Is the
world really crying out for yet another insecure messaging
protocol?

<MKA>

Much of Web Services (REST or SOAP) architectures of today are being developed without security models. Also, failure over the net (internet/VPN) are not being addressed sufficiently. WS-Security is new, and I wait to see what we come up with.

Security is often left to a different department or layer, and the explanation for current Web Services is that security has to be at layers above the transport layer (where Web Services is supposed to deal with). My professor Noel, and I myself have been in a thick spot trying to mention the importance of security at design time -- and I have had a bad experience even mentioning it. :) Security is misunderstood widely. For example, at Cisco, when I mentioned IT security they understood it as Network security (and felt slightly offended that I had undermined the capability of security in Cisco routers). When I explained about IT security being different from Network security ... it was an essay that didn't make sense -- because on the internet domain we are so habituated to undermine security.

These are the reasons why trust is difficult to come by for corporations that have been burned by the "silver bullet" promises from technology. So, the next time business is skeptical about the promises from technology or at least argue or play us down; a part of that blame comes from technology not "listening" to the actual business needs. Stakes in Web Services will increase, I believe, with improved security.

PS: These are not rants, it is just that I have ceased to be surprised when security is not given its due importance.

</MKA>

Logically, it doesn't make sense to me to design an
internet scale communication protocol without starting from a
security model.

Tyler

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Make Money Online Auctions! Make $500.00 or We Will Give You Thirty Dollars for Trying!
http://us.click.yahoo.com/KXUxcA/fNtFAA/uetFAA/W6uqlB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
rest-explore-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

On Thursday 01 May 2003 12:54, Chuck Hinson wrote:
> I guess a better term
> for what I was thinking is security through obfuscation.

That is also incorrect.

"security through obfuscation" refers to a security mechanism with
no theoretical backing. Typically, this means that the security
mechanism is deliberately made hard to understand and/or is
undocumented. The hope is that the attacker won't bother trying to
figure out what is being done.

For example, for ciphers, it is a tenet that all the security
should be in the key and that the algorithm should be public. In
times gone by, some people believed that security could also be in
the algorithm and that the algorithm should be kept secret.  This
is an example of "security through obfuscation".

When using a nonce for authentication, all of the security rests
in the randomness of the nonce. There is strong theoretical
backing for building an authentication mechanism on this.

> Along with all the other books I need to pick up that are more closely
> related to the kind of work I do.  Maybe one day I'll be involved in a
> project that has more stringent security requirements.  Unfortunatley,
> until that time comes, I'm not likely to devote much more than a passing
> interest to the subject (and as a result, continue to demonstrate my
> ignorance).

That's fine. I'm not trying to pick on you or anything. It's just
that the whole authentication sub-thread had completely left the
tracks, and I thought you might want to know.

I have to admit that I do find it very strange that this group is
designing a communication protocol with no security model. Is the
world really crying out for yet another insecure messaging
protocol? Logically, it doesn't make sense to me to design an
internet scale communication protocol without starting from a
security model.

Tyler

Tyler Close wrote:

>The aphorism "security through obscurity" refers to the shunned
>practice of using a security mechanism that has not been subjected
>to widespread study. This approach is motivated by the hope that a
>potential attacker will pick a different target, since he is not
>likely to have a pre-formulated attack, and will see little
>leverage to be had in developing a new attack against an "obscure"
>system.
>
>
Hmm.  OK.  Well now that you put it that way, it seems that I've been
working with a bad definition all these years.  I guess a better term
for what I was thinking is security through obfuscation.  In any case,
that doesnt change the correctness of your statement.

>The use of a randomly generated secret for authentication purposes
>has nothing to do with "security through obscurity". Use of a
>nonce in an authentication protocol is standard practice. I
>suggest you pick up a book on cryptographic protocols.
>
>
Along with all the other books I need to pick up that are more closely
related to the kind of work I do.  Maybe one day I'll be involved in a
project that has more stringent security requirements.  Unfortunatley,
until that time comes, I'm not likely to devote much more than a passing
interest to the subject (and as a result, continue to demonstrate my
ignorance).

--Chuck

>
>

Tyler Close wrote:

>On Thursday 01 May 2003 11:02, Tyler Close wrote:
>
>
>>A URI is also not something you "have", it is something you
>>"know". A URI is not physical.
>>
>>
>
>Just so that no one gets confused, I want to add emphasis to this
>part. The crux of "something you have and something you know" is
>that you are partitioning the authentication mechanism, thus
>requiring the attacker to execute two separate attacks in order to
>be successful.
>
>For example, in the ATM case, if the attacker shoulder surfs your
>PIN, he does not gain the ability to make a withdrawal. Similarly,
>if you lose your wallet, the attack does not gain the ability to
>make a withdrawal. The attacker must find your wallet and then
>shoulder surf your PIN in order to be successful. The attacker is
>unlikely to get both secrets in a single attack.
>
>Requiring something you "have" and something you "know" partitions
>the authentication mechanism so that a single breach is unlikely
>to give up all the authentication information. The fact that part
>of the authentication mechanism is physical and part of it is
>knowledge means that the parts are likely kept seperately and thus
>not vulnerable to a solitary attack.
>
>Obviously, this aphorism does not apply to the HTTP Auth versus
>capability debate, since neither employs a physical element.
>
>
I hesitate to reply since my knowledge of security is pretty limited.

Perhaps I stretched the have/know aphorism a little far, but the way I
look at it, electronic documents/files qualify as something you have -
they exist outside of your head and can be obtained by someone else
without your involvement.  Ideally, something you know doesnt exist
outside of your head, and for the most part, can't be obtained without
your involvement.  Thus, a notification, while not a physical, is
certainly something you can possess.  The password (as long as it isnt
disclosed as part of the notification) is something you know.

Anyway, as I said above, I really don't know enough about security to
really stand behind what I've said, so if you respond by telling me I'm
all washed up, then I'll have to leave it at that.  I don't mean to wimp
out of the discussion, I just dont have the time, interest or mental
horsepower at this point to continue the debate.

--Chuck

Seairth Jacobs wrote:

>From: "Michael Day" <mikeday@...>
>
[. . .]

>
>
>>Okay, so it is for when I have a temporary connection and I want to grab
>>all the available notifications from a server in one lump. That seems
>>perfectly reasonable. I do think it is worth allowing documents with a
>>single notification element, as it is shorter, simpler and no harder to
>>process (XPath: //notification will grab all notifications either way, and
>>a single XSL template for notification would handle both cases).
>>
>>
>
>Also, it occurred to me this morning that the <notifications> was currently
>only being used in a pull situation.  What if RNA were to strictly enforce
>that rule?  In other words:
>
>PULL returns <notifications>
>PUSH sends <notification>
>
>This would mean that if a server needed to push several notifications, it
>would have to do them one at a time.
>
>
Why make a special case?  And why force PUSH to only send one
notification at a time?  It seems like an arbitrary restriction that
reduces the ways in which PUSH might be used.  For instance, what if I
want to batch my PUSHes - seems like I have to incur a lot of overhead
for what appears to be an arbitrary decision.

Unless somebody can make a compelling case otherwise, I think you're
much better off starting off with a single document root using notications.

--Chuck

On Thursday 01 May 2003 11:02, Tyler Close wrote:
> A URI is also not something you "have", it is something you
> "know". A URI is not physical.

Just so that no one gets confused, I want to add emphasis to this
part. The crux of "something you have and something you know" is
that you are partitioning the authentication mechanism, thus
requiring the attacker to execute two separate attacks in order to
be successful.

For example, in the ATM case, if the attacker shoulder surfs your
PIN, he does not gain the ability to make a withdrawal. Similarly,
if you lose your wallet, the attack does not gain the ability to
make a withdrawal. The attacker must find your wallet and then
shoulder surf your PIN in order to be successful. The attacker is
unlikely to get both secrets in a single attack.

Requiring something you "have" and something you "know" partitions
the authentication mechanism so that a single breach is unlikely
to give up all the authentication information. The fact that part
of the authentication mechanism is physical and part of it is
knowledge means that the parts are likely kept seperately and thus
not vulnerable to a solitary attack.

Obviously, this aphorism does not apply to the HTTP Auth versus
capability debate, since neither employs a physical element.

Tyler

A number of the arguments made in this sub-thread about
authentication have made incorrect reference to security
aphorisms. I thought it would be helpful if I explained what the
actual meaning of each aphorism is.

On Thursday 01 May 2003 10:00, Chuck Hinson wrote:
> (something you have - the URI, and something you know - the
> username/password), etc.

The aphorism "Something you have and something you know" refers to
an approach for doubling up on authentication mechanisms.

For example, your ATM card employs this approach. In order to make
a withdrawal from an ATM, you must have your ATM card and you must
know the corresponding PIN. Each of these mechanisms is a secret
that by itself provides client authentication. Possession of the
card authenticates the customer, as does knowledge of a secret
passcode. Since humans are so careless, the ATM requires the human
client to execute both authentication mechanisms. This way, if the
careless human loses only one of the secrets, the attacker does
not gain the ability to make a withdrawal.

The HTTP Auth mechanism of having a guessable URI and a separate
username/password is *not* an application of the "Something you
have and something you know" aphorism. The guessable URI does not
provide any authentication. A URI is also not something you
"have", it is something you "know". A URI is not physical.

On Thursday 01 May 2003 03:12, Michael Day wrote:
>  * Generated user/password. Purely security through obscurity, require an
>    arbitrary generated user/password that is only sent to the recipient.

The aphorism "security through obscurity" refers to the shunned
practice of using a security mechanism that has not been subjected
to widespread study. This approach is motivated by the hope that a
potential attacker will pick a different target, since he is not
likely to have a pre-formulated attack, and will see little
leverage to be had in developing a new attack against an "obscure"
system.

The use of a randomly generated secret for authentication purposes
has nothing to do with "security through obscurity". Use of a
nonce in an authentication protocol is standard practice. I
suggest you pick up a book on cryptographic protocols.

Tyler

From: "Chuck Hinson" <cmhinson@...>
>
> But my point was that if you're going to give the recipient a token
> (username/password), you might as well use the randomly generated URI
> because you can forgo the setting up an account and using http auth.

Not entirely, I think.  If you were sending a notification to multiple
recipients, for instance, you would have to either:

1) Assign multiple URIs to the same resource, one for each recipient
2) Assign a single URI with multiple user/pwd pairs, one for each recipient

Without either of these approaches, it would not be possible to know which
recipient was accessing the resource.  Personally, I prefer the single URI
approach.

---
Seairth Jacobs
seairth@...

From: "Michael Day" <mikeday@...>
>
> > This is just the format it takes going over the wire.  A server may
choose
> > to store it locally as several one-notification resources.  The only
time I
> > can think of where <notifications> would be necessary is when they are
being
> > pulled instead of pushed.  When being pushed, a server could just as
easily
> > (ignore network overhead, etc.) send several individual notifications...
>
> Okay, so it is for when I have a temporary connection and I want to grab
> all the available notifications from a server in one lump. That seems
> perfectly reasonable. I do think it is worth allowing documents with a
> single notification element, as it is shorter, simpler and no harder to
> process (XPath: //notification will grab all notifications either way, and
> a single XSL template for notification would handle both cases).

Also, it occurred to me this morning that the <notifications> was currently
only being used in a pull situation.  What if RNA were to strictly enforce
that rule?  In other words:

PULL returns <notifications>
PUSH sends <notification>

This would mean that if a server needed to push several notifications, it
would have to do them one at a time.

---
Seairth Jacobs
seairth@...

From: "Michael Day" <mikeday@...>
>
> There are five methods of authentication:
>
>  * No authentication. Useful for public messages, mailing lists and so on,
>    or when the server itself is behind a corporate firewall.
>
>  * Persistent user/password. Useful for when you are receiving messages
>    from a server on which you already have an account of some kind.
>    For example, corporate mail server, Microsoft passport (ugh), or some
>    kind of ISP mail gateway.
>
>  * Generated user/password. Purely security through obscurity, require an
>    arbitrary generated user/password that is only sent to the recipient.
>
>  * Generated URL. This is identical to the previous method. Both of these
>    methods of course break down when someone else gets hold of the URL.
>
>  * Public Key Infrastructure. I don't know much about this, but it seems
>    to be the only way of ensuring the person retrieving the message is the
>    person that the message is sent to, based on their public key.

Good list!  To me, RNA currently provides the infrastructure for the first
four, but only because this is already basically available with HTTP.  I
have left PKI out because I do not necessarily want to endorse one strategy
over another...

---
Seairth Jacobs
seairth@...

From: "Michael Day" <mikeday@...>
>
> > Umm... I think the only reason was because of the complexity of
embedding
> > URIs in query parameters.  However, you are fundamentally correct.  GET
> > would be a better choice here.   I'll have to take a shot at converting
it
> > to GET semantics (any help here is appreciated).
>
> Alternatively, if every notification is itself a resource you can simply
> GET the notification. Much simpler and no URI syntax mangling.

Except for two things:

1) the query still needs the recipient to identify themselves to the sender.
2) querying the notification does not prove that the stated sender is the
actual sender.  For instance, suppose you had the following:

From: http://seairth.com/rna
Notification: http://notifications.rnaserver.com/2344993456223
Resource: http://www.cnn.com

In this scenario, it is obvious that asking rnaserver.com would not prove
that I sent the notification.  Even if the notification and the sender were
on the same server, there's still not guarantee.

However, if the notification has a URI, it may be more appropriate to query
if a "notification" was sent by a user instead of "notification of a
resource".  At the same time, instead of returning the notification as the
response, a simple 204 would suffice.  The only risk I can still see
happening is if a third-party alters the sender's notification, the sender
will not necessarily be aware of this fact... though I suppose the sender
*could* get the notification and evaluate it before returning the ACK/NAK
response to the recipient query...

---
Seairth Jacobs
seairth@...

p.s. It just occurred to me that some of the assertions/statements above
appear "out of the blue".  This is because, as I noted to Chuck, the idea of
assigning URIs to the notifications is something I had been doing pre-RDF.
The assertions you are seeing (e.g. that the notifications may not be within
the path of the sender URI) are from that work.

Seairth Jacobs wrote:

>From: "Chuck Hinson" <cmhinson@...>
>
>
>>In thinking about this, there seems to be a larger problem.  What's to
>>prevent someone from reading messages not intended for them by simply
>>guessing URIs?  Seems to me that if I get a notification from you with a
>>resource URI of http://seairth.com/rna/msg/1234, it wouldn't be much of
>>a stretch to try .../msg/1235, .../msg/1236, etc.
>>
>>Perhaps messages should have large, randomly assigned values for their
>>ids.  Security is then based on the fact that you (the recipient) know
>>the message id.  As someone else (Tyler Close) argued about
>>capability-base security, its just as hard to guess a randomly generated
>>128 bit number as it would be to guess a username and password.  (I'm
>>still not completely comfortable with the idea of capability-based
>>security that uses really long, randomly generated URIs - seems too much
>>like security through obscurity)
>>
>>If you believe that its impractical to guess the URI of the message,
>>then you really dont need the username and password.
>>
>>
>
>First, I think it's entirely reasonable to generate a long, random character
>sequence in place of use of a user/pwd.  I don't see out this would be any
>different than prepending a random "user:pwd@" to the URI instead.  I think
>the only real security risk is the ease with which a URI can be passed
>around, stored in "favorites", etc.  Keeping the user and password separate
>from the URI seems less prone to accidental sharing of authentication
>information.  But I don't know for sure...
>
>
I dont disagree, and I have the same nervousness about using something
as both the name and the access token.  While I know almost nothing
about capability-based system, I cant help feeling that it violates
commonly accepted principles like separation of concerns, security in
layers (something you have - the URI, and something you know - the
username/password), etc.

But my point was that if you're going to give the recipient a token
(username/password), you might as well use the randomly generated URI
because you can forgo the setting up an account and using http auth.

--Chuck

>If using user/pwd, however, implementations can vary.  For instance, you
>could assign a unique user/pwd to each resource.  Or you may assign the same
>user with different pwds for each resource that will be accessible by the
>same person.  Or, you could even use the same user/pwd every time.  The
>point here is that the exact implementation is not set in stone by RNA.  Any
>of these approaches would work, each with their advantages and
>disadvantages.
>
>I should probably increase the text in authentication example to cover these
>options...
>
>---
>Seairth Jacobs
>seairth@...
>
>
>
>To unsubscribe from this group, send an email to:
>rest-explore-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

From: "Chuck Hinson" <cmhinson@...>
> In thinking about this, there seems to be a larger problem.  What's to
> prevent someone from reading messages not intended for them by simply
> guessing URIs?  Seems to me that if I get a notification from you with a
> resource URI of http://seairth.com/rna/msg/1234, it wouldn't be much of
> a stretch to try .../msg/1235, .../msg/1236, etc.
>
> Perhaps messages should have large, randomly assigned values for their
> ids.  Security is then based on the fact that you (the recipient) know
> the message id.  As someone else (Tyler Close) argued about
> capability-base security, its just as hard to guess a randomly generated
> 128 bit number as it would be to guess a username and password.  (I'm
> still not completely comfortable with the idea of capability-based
> security that uses really long, randomly generated URIs - seems too much
> like security through obscurity)
>
> If you believe that its impractical to guess the URI of the message,
> then you really dont need the username and password.

First, I think it's entirely reasonable to generate a long, random character
sequence in place of use of a user/pwd.  I don't see out this would be any
different than prepending a random "user:pwd@" to the URI instead.  I think
the only real security risk is the ease with which a URI can be passed
around, stored in "favorites", etc.  Keeping the user and password separate
from the URI seems less prone to accidental sharing of authentication
information.  But I don't know for sure...

If using user/pwd, however, implementations can vary.  For instance, you
could assign a unique user/pwd to each resource.  Or you may assign the same
user with different pwds for each resource that will be accessible by the
same person.  Or, you could even use the same user/pwd every time.  The
point here is that the exact implementation is not set in stone by RNA.  Any
of these approaches would work, each with their advantages and
disadvantages.

I should probably increase the text in authentication example to cover these
options...

---
Seairth Jacobs
seairth@...

> This is just the format it takes going over the wire.  A server may choose
> to store it locally as several one-notification resources.  The only time I
> can think of where <notifications> would be necessary is when they are being
> pulled instead of pushed.  When being pushed, a server could just as easily
> (ignore network overhead, etc.) send several individual notifications...

Okay, so it is for when I have a temporary connection and I want to grab
all the available notifications from a server in one lump. That seems
perfectly reasonable. I do think it is worth allowing documents with a
single notification element, as it is shorter, simpler and no harder to
process (XPath: //notification will grab all notifications either way, and
a single XSL template for notification would handle both cases).

> And I am also trying to avoid the association of "message".  I feel that if
> people start thinking of these things as "messages", they will start putting
> more in the notifications and less in the resources being pointed to.  I'm
> really trying to keep the distinction as clear as possible.

You're right, a notification is neither a message, nor an envelope, but
rather a notification that a message is available. It just gets a bit
blurred when notifications are themselves resources used for storing
message metadata. Perhaps it is worth differentiating these two cases for
clarity... the representation sent to someone telling them that a message
is available is definitely a notification, while the resource that can be
accessed to retrieve message metadata and links to the message body is
presumably the message itself, or the CNN homepage, or the whatever...
okay I see now that no single description is required for the resource
that the notification concerns.

> See?  It was meant to be. :) (okay,I might be stretching it a bit...)

Every new spec needs a cool acronym; at least it's better than "SOAP" :)

Michael Day

YesLogic Pty. Ltd.