WebID-ISSUE-34: Create a security considerations section (was [foaf-protocols] Webid Spec: Security Considerations Section?)

---------- Forwarded message ----------
From: Akbar Hossain <akkiehossain@gmail.com>
Date: Sun, Aug 15, 2010 at 5:52 PM
Subject: Re: [foaf-protocols] Webid Spec: Security Considerations Section?
To: Henry Story <henry.story@gmail.com>
Cc: foaf-protocols@lists.foaf-project.org


Hi Henry,

The rewording is great! ( May have to re-read a few more times )

On Sun, Aug 15, 2010 at 11:33 AM, Henry Story  <henry.story@gmail.com>
wrote:
> (Some of these points are just rewordings of what Akbar wrote)
>
> - There are issues around WebIds with insecure protocols such as http://or ftp://.
>
> - Sections on cryptosticks and other hardware devices
>  [ question for us: should we add something about this to the ontology? So
that when a public key's private key is hardware only the user can specify
this in his foaf? ]

Yes it would be helpful to have an agreed way to express a policy in
your WebID and if hardware sticks is a growth area for WebID from a
end user viewpoint then it seems a good place to start. I think some
people also use hardware on servers to store keys and accelerate SSL
so might be worth looking into that too.

I don't understand the significance of expressing "I have a hardware
only X.509 for being able to prove the private/public key pairing" or
rather how this would be communicated to the verifying agent on the
TLS connection as I havent played with a stick yet but I was planning
on getting one (looks like I will need to get one immediately if not
sooner). Of course as a verifier I may trust a person with a hardware
key a bit more. Giving folks a standardised way to express "this is
way I will prove ownership of my webid anything else is not me" has to
be a good thing. It is peer to peer. Little different to my comments
on the Multiple SANs. "I will not be using multiple SANs". "I do not
want you to rely on a cache my WebID". These are all expressions of my
wishes. A verifier may ignore it but they should know I will not
accept what they are saying about me if they cant prove they followed
my wishes, that they were observed and adhered to.

Partially related. OpenID were working on this.
http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-01.html
Not sure where they got to.

At the moment the implied process to verify the association of a X.509
certificate and your WebID is the TLS protocol.
Which is fine but possibly doesnt need to be. It would be a lot of
work for little gain at this stage but I am not sure TLS (or HTTPS)
is needed for this all to work. The spec is currently based on a TLS
connection to the verifying agent however the ontology only seems to
specify the RSA Public Key wondering if what is required is a triple
that expresses the protocol the verifier should use to communicate
with the identifying agent.

I think this would probably also allow a merge with the delegated
foaf+ssl scheme at somepoint.

> - One should explain what is known by the server from the process: the
WebId and nothing more. All the rest of the information in the foaf is
asserted by the wid.

Absolutely. This is the reason the attack I outlined on the other
email will probably work. Verifiers will think they can do things with
information on the X.509 without checking all the links (seeAlso) and
back links or they think the can rely on a cache. I can use the same
PublicKey (or different keys) in different points of my distributed
graph but any caching or assumptions about links and backlinks will
probably be exploitable.

In my view this and the next points are very very critical to get across.

Thanks

> - How the fact that information in the foaf profile even though being
asserted can be trusted more than just an assertion, say if other poeple one
knows point to it. It should be pointed out that there are many ways other
information can be used to increase the trust of some information.
>
> - It may be worth having a section about how if the
foaf:PersonalProfileDocument points to another document, which points back
to the foaf, one can consider this as a form of validation.
>
>
> Perhaps there should be a section on reasoning with the information that
covers the last three points.
>
> By the way one could have a philosophical introduction to knowledge, such
that all knowledge is defeasible. Robert Nozick's definition of knowledge in
Philosophical Explanations is very interesting and worth considering.
>
> S knows that P if and only iff
>
>  - P is True
>  - S believes that P
>  - if P were not true S would not believe it
>  - if P were true S would believe it
>
> The interesting thing about this definition of knowledge is that it shows
how it is possible that I know I am writing this from Fontainebleau France,
even though I don't and can't know I am not a brain in a vat on alpha
centauri. ( Nice summary here:
>  http://www.erin.utoronto.ca/~jnagel/333h16.htm )
>
> Security is very much like knowledge: one can be more secure, but one can
always find counterexamples that would leave one wondering if one can be
secure at all.
>
>
> Henry
>
> On 15 Aug 2010, at 08:59, Akbar Hossain  wrote:
>
>> So I think on the dereferencing of webid stage
>> [
http://getwebid.org/spec/#verifying-the-webid-is-identified-by-that-public-key
]
>> you can try to
>>
>> 1. Mount a Denial of Service attack when a verifying agent tries to
>> deference a WebID.
>>
>> 2. Try a Man in the Middle attack when dereferencing the WebID unless
>> some counter  measure is employed.
>>
>> 3. Eavesdropping again unless some counter measure is employed
>>
>> All covered in the paragraph already there I think.
>>
>> I think there are some considerations related to
>> [http://getwebid.org/spec/#initiating-a-tls-connection] but they maybe
>> temporal around the DNSSEC and Renegotiation stuff.
>>
>> 4. Denial of Service on the resource you are trying to access in the
>> first place.
>>
>> Any others?
>>
>> [ Having said all that - I was just looking at
>> http://tools.ietf.org/html/rfc2818#page-6.
>>
>> "Security Considerations
>>
>>   This entire document is about security." ]
>>
>>
>>
>> On Sat, Aug 14, 2010 at 11:46 PM, Dan Brickley <danbri@danbri.org> wrote:
>>> On Sat, Aug 14, 2010 at 9:46 AM, Akbar Hossain   <akkiehossain@gmail.com>
wrote:
>>>> Hi,
>>>>
>>>> I was looking thru the the RFC for HTTP Authentication: Basic and
>>>> Digest Access Authentication recently.
>>>>
>>>> http://tools.ietf.org/html/rfc2617
>>>>
>>>> I quite like the way there is a section on security considerations
broken out.
>>>>
>>>> http://tools.ietf.org/html/rfc2617#section-4
>>>>
>>>> Might want to consider that for the WebID spec?
>>>>
>>>> I see there is one consideration in section 3.
>>>>
>>>> http://getwebid.org/spec/#secure-communication
>>>>
>>>> Breaking out into its own section might encourage a fuller list of
>>>> security consideration and elevate it.
>>>>
>>>> Thoughts?
>>>
>>> I'd welcome this...
>>>
>>> Dan
>>>
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols@lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>
>
_______________________________________________
foaf-protocols mailing list
foaf-protocols@lists.foaf-project.org
http://lists.foaf-project.org/mailman/listinfo/foaf-protocols