WebID RSA - some questions

I think this is in general a very good idea and will be needed for HTTP2.0 as TLS cannot be used there.
It does require cryptography in the browser, as I understand. Which browsers support those? Do we know what the UIs for those look like currently? How does the user select a public key to authenticate with? It would be good to have a section dedicated to that - a wiki page perhaps. And the particular protocol could be specified on the WebID Specs page.

Second as a WebID can have more than one key, my guess is that the browser has to send the public key as a link or in the header to the server. Otherwise the server needs to test each WebKey listed in the WebID Profile, and there may be a few.

I think there could be a better name too. RSA is a cryptographic algorithm, whereas what you are defining here is a protocol. Perhaps

WebID-Token-Auth
WebID-JS-Auth
...

Re: question 1

http://caniuse.com/#feat=cryptography

First of all, thanks for looking at this document! I'm happy we're getting feedback. Now, to answer your questions:

There is currently no UI, since the Webcrypto API spec doesn't mandate one. Their reasoning was that keys can come from anywhere -- e.g. localStorage, OS-based keystore, smart cards, etc. Right now I plan to write a client app that generates the key pairs using built-in Webcrypto support in browsers, and then stores them on the user's server using LDP. The same app will handle the retrieval of keys. Authentication will take place in this app/widget and the underlying app (i.e. Cimba) will either require access to the credentials (dangerous but useful), or it will ask for a session key (similar to a cookie).

My intuition is that 99% of people will have one or maybe two keys in their WebID profile. Having 10 keys still doesn't make it too big of a problem, since this particular authentication process happens once (and on demand!), before a secure cookie is generated.

Re. protocol name, I still think that WebID-RSA is a fitting name since only RSA keys are used in this specific version of the protocol.

@deiu

Thanks for writing this out too @deiu . I can see a lot of potential in the WebID-RSA.

It is odd that the browser vendors thinking that the key can come from anywhere, don't give a UI to help the user select it from somewhere. Otherwise the potential for phishing is pretty high, and the security issues of loosing the private key pretty high.

It may require one to save the private key on the server too, which creates a whole different set of issues. One may wonder in that case if one really needs the JS crypto in the browser or if sending the to be encrypted token to the home server which would then encrypt it and return it would not do just as well. Still even then the security of the token in the browser needs to be taken care of.

It seems there is a need for a more detailed specification first before we can really make it part of the SoLiD platform, otherwise it looks a bit like SoLiD is vapourware, when in fact we already have a lot of implementations for most of it. So that we need a way to specify implementation levels which is issue #6

On the other hand I think we could use this even better for server to server communication, where it makes sense for the server to act on behalf of a client and where such an authentication scheme can be very helpful.

FYI: https://w3c.github.io/webappsec/specs/credentialmanagement/#existing-solutions-webid

Hi, please take a look at "Signing HTTP Messages" (or "http-signatures" for short) at the IETF: https://tools.ietf.org/html/draft-cavage-http-signatures-04

I'm pretty sure it accomplishes what the WebID-RSA proposal is looking do. A version of it is already in use by Joyent. The implementation is here: https://github.com/joyent/node-http-signature

A PR bringing that implementation up to the latest version of the spec is here: TritonDataCenter/node-http-signature#42

Other notes: It's already been reviewed by Mark Nottingham and others who worked on HTTP 2.0; http-signatures is designed to be compatible with both HTTP 1.1 and HTTP 2.0.

Thanks for bringing this up. I'll take a look at it.

I hope I'll get to chance to meet some folks in Prague for the IETF meeting to discuss this.

@dlongley

@dlongley re:

GET /data/ HTTP/1.1
Host: example.org
Authorization: Digest username="https://alice.example.org/card#me", 
                  nonce="securestring",
                  sig="signatureOverUsernamePlusNonce"

The two concepts look quite close. In terms of aligning them further, there's a number of items, but could I first look at username vs keyId

In HTTP signatures the keyID is opaque and denotes a key, in WebID-RSA the username is a URI that denotes a Person
In HTTP signatures the keyID is sent in the response, in WebID-RSA the keyId is sent in the request

Did I get that right?

See: 3.1.2. [Authentication] RSA Example

https://tools.ietf.org/html/draft-cavage-http-signatures-04#section-3.1.2

@melvincarvalho

@melvincarvalho,

In HTTP signatures the keyID is opaque and denotes a key, in WebID-RSA the username is a URI that denotes a Person

There are no restrictions on the meaning of keyId (yes, it is opaque) in the specification. It may, for instance, be formatted as a URI that refers to a public key or it may be some other kind of identifier entirely. The meaning of the keyId identifier is decided by the application.

In HTTP signatures the keyID is sent in the response, in WebID-RSA the keyId is sent in the request

In HTTP signatures, both requests and responses may be digitally signed. Whenever either is signed, the keyId is a required parameter. So to be clear, the above is incorrect in that it is incomplete, keyId may certainly also appear (and it's the more typical case) in the request.

@dlongley

@dlongley thanks for the clarification, sorry my knowledge is basic being new to the spec today. So part (2) is already partially aligned for us (good news!) :)

So the first question of alignment comes down to whether keyId could be reused as a webid. Certainly the spec allows this, the question is whether the naming might be misleading. Something to think about, I suppose. Thinking out loud: if SoLiD decided to adopt HTTP signature style, could a phrase be added to the spec saying that keyId could be used to denote a person as some kind of indirect identifier, maybe 6-10 words to that effect -- not a request at this stage, just curious.

Some more questions

If i've understood correctly we would need to change nonce to be a header, then have a headers field detailing nonce and "source" which we had orriginally put in Www-Authenticate.

Www-Authenticate: WebID-RSA source="https://public.databox.me/Public/acltest", nonce="MTQzODU1NzQ2NnxXWFFldU1MUG50MDE0T1YxdXNTMUVTZXJ5R1hBVVVRTkxHN1NmdV8zRHBMb2hsZzZ5SklEbUtTcEZyZFdyVWhQSjcwdW53RHhwTmh5MTlQOTBTNEJHZDNuLVFQZ3zfgDYC_jsdCvms8d7bzk0hEYQUYssHa0OYDDSpCNmUgQ=="

Any thoughts on this design decision?

Then I think we'd need a header called headers saying source,nonce?
Also we'd need an algorithm in the registry? I think currently we are just base64 encoding the pkcs1 v15 -- do you have experience of this approach

Thanks again for the feedback, learning from the master here! :)

@dlongley

@dlongley that spec looks very interesting. I wonder if there is a subset of it, that would not require signing the whole content. If we assume we are already working on TLS, then it looks like there is no need to secure the whole content too. The WebID-RSA already contains the name of the domain to which authentication is being applied.
@melvincarvalho I think in this case using the URI of a web key may actually be better, because as opposed to WebID-TLS where the server knows the public key to use, here the server does not.

@melvincarvalho

@melvincarvalho,

Regarding nonces, here's the draft spec for a nonce extension to http signatures: https://web-payments.org/specs/source/http-signature-nonces/

So the first question of alignment comes down to whether keyId could be reused as a webid.

You could, but then you'd have to guess (or send additional information somehow) as to which key was used to sign. As @bblfish points out, it would be simpler to use the URI of a web key directly. Linked data can always be used to place an assertion on the web key tying it to its owner (which can then be checked for a similar reverse-relationship). HTTP signatures should work nicely with WebID.

Also we'd need an algorithm in the registry? I think currently we are just base64 encoding the pkcs1 v15 -- do you have experience of this approach

Base64 encoding the pkcs#1 v1.5 is what's done with the rsa-sha1 and rsa-sha256 algorithms in the spec as currently defined. There's some discussion in the spec about being more explicit about things like padding types, which I personally recommend we do in the spec algorithm identifiers.

@bblfish,

I wonder if there is a subset of it, that would not require signing the whole content.

You can pick and choose which headers to sign. You don't have to sign a digest header (with a digest on the body) if you don't want to. Does that answer your question? Is that what meant by "signing the whole content"?

@dlongley

@dlongley thanks for the clarification, about not having to sign the whole body. I was worried that

that means one has to have the whole body ready to calculate the has, which for longer bodies may be a lot of work and use up memory
that this may be problematic for JS XMLHTTPRequests where the client does not control all the headers

Another question relating to using this in Browsers, which I think you are interested in too, that I asked on the TAG recently and on the blink dev discussion about removing keygen was how to deal with the following scenario:

What WebID-RSA allows one to do with WebCrypto, is to to authenticate across origins by using public key cryptography, which then sets a cookie, allowing the browser to download all other types of content.

The problem is that one may perhaps not want or be able to authenticate immediately to a web site. Imagine that JS from Origin https://bblfish.net/ follows links to the server https://people.w3.org/ . Let's imagine that the data it reaches there first is all public, describing the roles of people, and their relations to blogs, w3c working groups, mailing lists, etc.... Let's imagine that due to privacy reasons some members of the W3C team don't have pictures posted publically,but protected by some access control rule.

Now my JS gets some JSON(-LD) data from the <https://people.w3.org> origin and builds up a DOM tree with inline <img src="/xxx/depiction.jpg"> elements. Can the JS intercept the 401 Unauthorized codes, in order to enable authentication using WebWorkers?

The response Ryan Sleevi gave to this ( apart from affirming that "this is unsound cryptography") was in a later message

Service Workers offer a potential avenue for this, allowing loads to be intercepted and rewritten. Handling authentication is one of the use cases envisaged for ServiceWorkers, albeit with many fundamental security limitations (e.g. that go beyond the cryptographic unsuitability of WebId-RSA). But you can certainly build a system on it.

Has anyone of you tested this?
It will also be useful to get to the bottom of what he thinks the security issue is, because if it is that the webcrypto is communicating across origins, then its clear he is going to try to block any attempt to capture 401s at some point later.

@dlongley

@dlongley Here is Ryan Sleevi's short remark on your proposal

If that is the draft you're proceeding with, yes, you should, because it's insecure.

However, that's an expired individual submission. It does not have any endorsement of the IETF or any WG. Anyone on the Internet can submit those and get a similar link.

I am not endorsing his comments, but given that he is able to remove things willy nilly from 2 browsers (Firefox and Chrome), its worth being prepared for that type of attack.

My guess is the protocol could be improved by adding the ChannelID info to the signature. Search for Man In the Middle attack in the Universal 2nd Factor Authentication document from the FIDO Alliance. Now is there a JS way to get hold of that on the client side?

@bblfish

@bblfish,

Has anyone of you tested this?

We haven't run tests with ServiceWorkers, no. It would be interesting to do, though.

Here is Ryan Sleevi's short remark on your proposal...

That seems to be an offhand comment in a separate conversation; I don't plan on responding to it.

I am not endorsing his comments, but given that he is able to remove things willy nilly from 2 browsers (Firefox and Chrome), its worth being prepared for that type of attack.

Thanks for the information. We've been following (off and on) the keygen conversation.

Now is there a JS way to get hold of that on the client side?

It's extremely unlikely that JS would ever get a hold of a TLS ChannelID directly, as leakage of this information would break its value. However, servers often bind their cookies to a particular ChannelID and, therefore, perhaps that binding could be extended by including cookie headers and values (which are available to the client) in the HTTP signatures used. The HTTP signature spec allows for any header+value to be included in the signature, and I believe, already recommends including the host header as a means to limit MiTM attacks (but, including cookie values that are ChannelID-bound should be an additional best practice protection).

@dlongley

@dlongley has there been a discussion on the http-wg about draft-cavage-http-signatures-04? I found a thread "Signing HTTP" started by Marting Thomson, but not much more. Or is the discussion going on elsewhere? ( I mentioned it today in that list )

@bblfish

@bblfish, I don't remember where discussion has taken place, a quick search indicated that there was some feedback and discussion on the http-auth mailing list: http://www.ietf.org/mail-archive/web/http-auth/current/msg01712.html

I know some discussion may have been off list and there was also some comparison discussion/review related to a similar spec by Stephen Farrell (http://tools.ietf.org/html/rfc7486).

Ah thanks. I was not aware of http-auth.

rww-play now actually implements HTTP Signatures.
Tested with curl. Next to see how this works with JS clients...

It is actually not that complex to implement. Here are the main files to look at

I still need to add a small piece to get from the WebKey to the WebID, which is more likely to be used for authentication in Web Access Control lists .

Closing, the discussion has moved to solid/solid#22 and similar issues.

Navigation Menu

Repository navigation

WebID RSA - some questions #5

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

WebID RSA - some questions #5

Description

Activity

melvincarvalho commented on Apr 24, 2015

deiu commented on Apr 24, 2015

bblfish commented on Apr 24, 2015

bblfish commented on Apr 26, 2015

elf-pavlik commented on May 2, 2015

dlongley commented on Jul 9, 2015

dlongley commented on Jul 9, 2015

deiu commented on Jul 10, 2015

bblfish commented on Jul 13, 2015

melvincarvalho commented on Aug 2, 2015

dlongley commented on Aug 2, 2015

melvincarvalho commented on Aug 2, 2015

bblfish commented on Sep 15, 2015

dlongley commented on Sep 15, 2015

bblfish commented on Sep 15, 2015

bblfish commented on Sep 15, 2015

bblfish commented on Sep 15, 2015

dlongley commented on Sep 16, 2015

bblfish commented on Sep 18, 2015

dlongley commented on Sep 18, 2015

bblfish commented on Sep 18, 2015

bblfish commented on Oct 21, 2015

dmitrizagidulin commented on Feb 29, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions