RadioTAG Specification 0.7 Draft
9 views
Skip to first unread message
Andy Buckingham
Feb 25, 2011, 8:45:29 AM2/25/11
to RadioTAG Application Team
Hello team,
Further to my last e-mail, below is a link to the live draft of the
next proposed spec document. This allows you to keep an eye on where
the team is going. I've prepared this draft as promised from all the
discussions we've had since the last published release (0.6).
Feedback as always much appreciated. Please note that this doesn't
currently include the OAuth work I talked about from the EBU as we're
waiting to hear back on the suitability before looking at inclusion.
For those that prefer to download a doc and read offline, there's a
PDF of the draft as of today 13:45 attached too.
Thanks and have a nice weekend.
Andy.
--
Andy Buckingham
RadioTAG Application Team Lead
RadioDNS Project and Global Radio (UK)
t: +44 (0)117 900 5357
e: andy.bu...@radiodns.org
w: http://radiodns.org/
Follow the RadioDNS Project via Twitter: @radiodns
Andy Buckingham
Mar 3, 2011, 2:51:48 AM3/3/11
to RadioTAG Application Team
Just to let those interested parties know, I've made a few amends and
added some inline comments to the draft specification after some
further thought. It should all update live in the Google Doc:
added some inline comments to the draft specification after some
further thought. It should all update live in the Google Doc:
Look forward to hearing your thoughts soon.
Andy.
Sean O'Halpin
Mar 4, 2011, 12:26:29 PM3/4/11
to RadioTAG developers
On Mar 3, 7:51 am, Andy Buckingham <andy.bucking...@radiodns.org>
wrote:
This is my first post to the list so I'll just quickly introduce
myself
by saying that my name is Sean O'Halpin and I'm a Senior Software
Engineer
in the Prototyping team in BBC R&D.
Here are some comments we have on the proposed RadioTAG spec version
0.7.
First, some context: The points below arose out of discussions between
Andy Buckingham of Global and Chris Lowis and myself of BBC R&D during
a day long meeting on Thursday 3 March 2011.
Chris and I have been tasked with working within the RadioTag
specification process to help facilitate three outcomes: a) that
manufacturers adopt the specification; b) that it delivers useful
functionality to our audiences; and c) that it meets BBC policy
guidelines, in particular our security requirements.
There are three main areas we would like to comment on: first on the
focus of the specification and what should be included in it; next on
the Authentication and Registration protocol; and finally on the
structure of urls.
We're working on addressing the issues we raise here and will email
our proposals to the list early next week.
** General focus of specification
We think the focus of version 1.0 of the RadioTag specification should
be on what is required to enable a device to submit a tag to a tagging
service. This includes only Registration and Tag Submission.
We're not sure about the Tagged Events Feed in its current form. It is
not required to enable a device to perform tagging. Agreeing on the
format of the feed and exactly what metadata is included could occupy
many hours of discussion. For that reason, we'd like to move it into
an extension to the spec. (We'd also like to make it as compatible as
possible with RadioEPG but we won't get into that discussion here.)
We would like to exclude Syndication - it's not required for the base
functionality of tagging and we believe it can be better handled
somewhere other than on the device (e.g. on a account management web
page) and by better mechanisms (e.g. via OAuth).
In short, we're arguing to simplify what is required on the device to
perform tagging. More capable devices could take advantage of
extensions to provide a richer experience.
** The Authentication / Registration protocol
The PIN code is the only thing that can be used to associate a user
with a device.
This means collisions, spoofing, mistakes in entry and the eventual
exhaustion of PIN numbers are possible.
For example, Alice hits Register on her radio and gets the PIN
number 1234. Bob hits Register on his radio a minute later and gets
the PIN number 1243. Alice goes to the web site and mistakenly enters
the PIN 1243. She has now associated her account with Bob's radio and
will have access any tags Bob makes from that point on. When Bob tries
to register he's told that the device is already registered. The only
way to change that is to have some functionality on the radio to
invalidate the device id (which we would need to add to the spec, as
it is required on the device). Charlie in the meantime, who doesn't
even have a radio, creates an account and enters the PIN 1234. He now
has access to Alice's tags.
Another problem is resource exhaustion and denial of service attacks.
A PIN number is returned for every request to /.../<device_id>/.../.
As there is no provision for validating device ids, there is no way of
preventing this.
This makes it possible to exhaust PIN numbers or cause a rollover by
making multiple registration requests. It also makes it possible to
prevent registration by tying up all allocatable PIN numbers for the
duration of the PIN timeout.
A 4-digit PIN number allows only 10,000 combinations. This means you
can have only that many pending subscriptions at any one time.
Another and perhaps more important problem with the current spec is
that the only form of authentication is the uniqueness of the device
id. If there is no way to guarantee this uniqueness, there is also no
way to guarantee the authenticity of the request. As there is no
authorization token involved, there is only the request's assertion
that the request is being made on behalf of the specified device. This
is too easy to spoof (especially if we follow the rest of the spec and
broadcast our device ids in urls - see next point below). In general,
security through obscurity is not secure.
The current protocol raises a number of issues, not least of which is
the lack of security. Using a short PIN as the only means of
identifying the association between a user and a device is
problematic.
** The URLs
There is a general problem with the form of urls which include the
device id as part of the path. Even though the request itself is
encrypted via HTTPS, the request url itself is not. This effectively
broadcasts your device id on the internet.
The proposed spec (0.7) has URLs of the form:
http://hostname/1.0/<params>/tag
Where params would be 'fm/ce1/c586/09580'
e.g.
http://hostname/1.0/fm/ce1/c586/09580/tag
We think a canonical form of the URL should start with the resource
and API version. In this case, the resource is the tag, not the
service, as it is the tag which is created as a consequence. The rest
of the parameters should be provided in the body of the request. Also,
we should stick to REST principles and use POST for adding a tag. So
the above would be (in pseudo-HTTP):
POST /tag/1.0 HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
service=09580.c586.ce1.fm&
device-id=PROTO01&
device-timestamp=2011-03-04T16:08:56+00:00&
timestamp=2011-03-04T16:08:56+00:00&
The actual locator for the individual tag resource after creation
would then be simply
http://hostname/tag/1
Andy suggested that instead of parsing the component parts of the
service string from RadioDNS and reconstituting them in the path, we
simply take the string as is and pass that to the server. This is a
great idea that at a stroke removes a lot of complexity from the spec.
Regards,
Sean
wrote:
> Just to let those interested parties know, I've made a few amends and
> added some inline comments to the draft specification after some
> further thought. It should all update live in the Google Doc:
>
> https://docs.google.com/document/d/175CC8iOXfU1ukPHdoEfiQxMh4XqOrrQvb...
> added some inline comments to the draft specification after some
> further thought. It should all update live in the Google Doc:
>
>
> Look forward to hearing your thoughts soon.
>
> Andy.
Hi Andy and everyone else,
> Look forward to hearing your thoughts soon.
>
> Andy.
This is my first post to the list so I'll just quickly introduce
myself
by saying that my name is Sean O'Halpin and I'm a Senior Software
Engineer
in the Prototyping team in BBC R&D.
Here are some comments we have on the proposed RadioTAG spec version
0.7.
First, some context: The points below arose out of discussions between
Andy Buckingham of Global and Chris Lowis and myself of BBC R&D during
a day long meeting on Thursday 3 March 2011.
Chris and I have been tasked with working within the RadioTag
specification process to help facilitate three outcomes: a) that
manufacturers adopt the specification; b) that it delivers useful
functionality to our audiences; and c) that it meets BBC policy
guidelines, in particular our security requirements.
There are three main areas we would like to comment on: first on the
focus of the specification and what should be included in it; next on
the Authentication and Registration protocol; and finally on the
structure of urls.
We're working on addressing the issues we raise here and will email
our proposals to the list early next week.
** General focus of specification
We think the focus of version 1.0 of the RadioTag specification should
be on what is required to enable a device to submit a tag to a tagging
service. This includes only Registration and Tag Submission.
We're not sure about the Tagged Events Feed in its current form. It is
not required to enable a device to perform tagging. Agreeing on the
format of the feed and exactly what metadata is included could occupy
many hours of discussion. For that reason, we'd like to move it into
an extension to the spec. (We'd also like to make it as compatible as
possible with RadioEPG but we won't get into that discussion here.)
We would like to exclude Syndication - it's not required for the base
functionality of tagging and we believe it can be better handled
somewhere other than on the device (e.g. on a account management web
page) and by better mechanisms (e.g. via OAuth).
In short, we're arguing to simplify what is required on the device to
perform tagging. More capable devices could take advantage of
extensions to provide a richer experience.
** The Authentication / Registration protocol
The PIN code is the only thing that can be used to associate a user
with a device.
This means collisions, spoofing, mistakes in entry and the eventual
exhaustion of PIN numbers are possible.
For example, Alice hits Register on her radio and gets the PIN
number 1234. Bob hits Register on his radio a minute later and gets
the PIN number 1243. Alice goes to the web site and mistakenly enters
the PIN 1243. She has now associated her account with Bob's radio and
will have access any tags Bob makes from that point on. When Bob tries
to register he's told that the device is already registered. The only
way to change that is to have some functionality on the radio to
invalidate the device id (which we would need to add to the spec, as
it is required on the device). Charlie in the meantime, who doesn't
even have a radio, creates an account and enters the PIN 1234. He now
has access to Alice's tags.
Another problem is resource exhaustion and denial of service attacks.
A PIN number is returned for every request to /.../<device_id>/.../.
As there is no provision for validating device ids, there is no way of
preventing this.
This makes it possible to exhaust PIN numbers or cause a rollover by
making multiple registration requests. It also makes it possible to
prevent registration by tying up all allocatable PIN numbers for the
duration of the PIN timeout.
A 4-digit PIN number allows only 10,000 combinations. This means you
can have only that many pending subscriptions at any one time.
Another and perhaps more important problem with the current spec is
that the only form of authentication is the uniqueness of the device
id. If there is no way to guarantee this uniqueness, there is also no
way to guarantee the authenticity of the request. As there is no
authorization token involved, there is only the request's assertion
that the request is being made on behalf of the specified device. This
is too easy to spoof (especially if we follow the rest of the spec and
broadcast our device ids in urls - see next point below). In general,
security through obscurity is not secure.
The current protocol raises a number of issues, not least of which is
the lack of security. Using a short PIN as the only means of
identifying the association between a user and a device is
problematic.
** The URLs
There is a general problem with the form of urls which include the
device id as part of the path. Even though the request itself is
encrypted via HTTPS, the request url itself is not. This effectively
broadcasts your device id on the internet.
The proposed spec (0.7) has URLs of the form:
http://hostname/1.0/<params>/tag
Where params would be 'fm/ce1/c586/09580'
e.g.
http://hostname/1.0/fm/ce1/c586/09580/tag
We think a canonical form of the URL should start with the resource
and API version. In this case, the resource is the tag, not the
service, as it is the tag which is created as a consequence. The rest
of the parameters should be provided in the body of the request. Also,
we should stick to REST principles and use POST for adding a tag. So
the above would be (in pseudo-HTTP):
POST /tag/1.0 HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
service=09580.c586.ce1.fm&
device-id=PROTO01&
device-timestamp=2011-03-04T16:08:56+00:00&
timestamp=2011-03-04T16:08:56+00:00&
The actual locator for the individual tag resource after creation
would then be simply
http://hostname/tag/1
Andy suggested that instead of parsing the component parts of the
service string from RadioDNS and reconstituting them in the path, we
simply take the string as is and pass that to the server. This is a
great idea that at a stroke removes a lot of complexity from the spec.
Regards,
Sean
Andy Buckingham
Apr 14, 2011, 9:50:28 AM4/14/11
to RadioTAG developers
In light of the observations drawn against the v0.7 early draft, it
has now been superseded by a live draft v0.7.1.
A new thread will follow shortly which introduces this new document.
has now been superseded by a live draft v0.7.1.
A new thread will follow shortly which introduces this new document.
Reply all
Reply to author
Forward
0 new messages