Subject: Re: [Int-area] Discussion about Federated Roaming

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 01 Mar 2008 20:29:49 +0100

HEllo Stefan and thank you for the email on int-area.

Although supposedly the authentication aspects are the most concern to
the wide-area roaming contexts you're dealing with - I agree in many
respects - I think there may also exist some aspects related to
securely accommodating mobility at network layer, as you seem to
approach mentioning at the end of the mail.

In no way I'm trying to deviate discussion from the authentication
aspects, and I support a get-together in Philadelphia on this topic,
I'll probably join it.  Let me just reply to one of your last points below.

Stefan Winter wrote:
> Hello!
> 
> My name is Stefan Winter of the National Research and Education 
> Network in Luxembourg, RESTENA. We are an ISP for academia and take 
> the lead in research and development of a global academic wireless 
> LAN federated roaming consortium: "eduroam". This is based on EAP and
>  802.1X exclusively.
> 
> In the course of development, prototyping and rollout of eduroam, we
>  have discovered that some areas of the relevant standards required 
> some tweaking or workarounds. After following IETF work for some 
> time, we also saw that some of the efforts exclude roaming use cases
>  from their agenda.
> 
> So far I've heard that we are by far the biggest federated 802.1X 
> roaming consortium at all, and I wonder if we are the only ones 
> seeing some items that could use a second thought when considering 
> roaming between independent administrative domains.
> 
> I will be at IETF71, and would like to invite anyone who is 
> interested in federated roaming scenarios for an informal 
> get-together to exchange ideas. I was planning to do this on Monday 
> evening, at a location that is still TBD, I'll follow up.
> 
> Below I've put together the most prominent items that are on our 
> radar right now to give you a glimpse of the issues we in eduroam are
>  dealing with.
> 
> The most prominent issue is the uneasy fact that RADIUS doesn't 
> provide a reliable transport and only basic security, while Diameter
>  has no implementations and NAS support in the wireless LAN area.
> With an EAP conversation requiring multiple, usually around eight, 
> roundtrips, and a packet path that may literally span the whole 
> world, this is a major concern. It also didn't particularly help that
>  in a recent discussion on dime, it was stated that Diameter doesn't
>  offer significant advances regarding roaming compared to RADIUS. We
>  tried to mitigate this by proposing RadSec, RADIUS over TCP+TLS [1],
>  and are pursuing this in the radext wg right now.
> 
> Another thing is that we have no sufficient signalling mechanism to 
> reach the end user if the 802.1X login couldn't be completed because
>  of an intermediary RADIUS proxy being down - due to the lack of 
> possibility to provide error messages in the 802.1X protocol, most 
> supplicants provide the unhelpful advice that "Probably the password
>  is wrong", which is wrong and generates user frustration. Some kind
>  of "hijacking" the EAP conversation by the last responsive proxy to
>  inject EAP-Notifications would be needed probably, but this is not 
> thought through in its entirety yet. I'm aware that there is a 
> security argument: not disclosing the reason for a failure may make 
> attacks more difficult, but still: it would then be desirable to at 
> least have the *option* of providing the info - right now it is 
> impossible.
> 
> Then, encapsulating EAP in RADIUS may sometimes lead to RADIUS 
> packets being so big that they have to be fragmented - not a 
> conceptual problem, but a practical one, because out-of-order 
> fragements, or even even in-order UDP fragments generate problems on
>  unclever firewalls more often than not. Especially EAP-TLS, where 
> both server and supplicant need to send large amounts of 
> (certificate) data turned out to be a real challenge. A draft about 
> that problem and a sketch of a possible solution is in the works.
> 
> Another thing that bugged us about RADIUS is the inability to contact
>  new auth servers "on the fly", for example when a new user realm is
>  observed. So far, we stacked together RADIUS servers in a
> realm-based aggregation hierarchy. A better approach, in combination
> with the TCP+TLS nature of RadSec, would be to use a dynamic lookup
> mechanism (e.g. DNS NAPTR/SRV) that allows to discover the
> authoritative home server for a user's realm and to verify that
> server's eligibility by examining the certificate. This is a concept
> we will try out in semi-production use in eduroam soon, but it may
> have implications also out of the eduroam community, since it will
> allow arbitrary service providers to create an authentication fabric
> very easily on the technical side - making the *paperwork* of
> bootstrapping a roaming consortium the only big challenge.
> 
> We have been looking at the work of the NEA wg with a bit of concern,
>  since its charter excludes the federated roaming case deliberately.
>  For example, putting posture information into EAP will always convey
>  the posture info to the home server, while it is the service
> provider that needs the posture information to make its admission
> decision. We understand though that there is work going on to make
> the use of NEA roaming-agnostic, which we would very much like to
> see.
> 
> Finally, there is a more exotic area in connection to roaming 
> scenarios: converging roaming on the network layer (802.1X+EAP) with
>  Single-Sign On on the application layer (SAML et al), with the 
> ultimate goal that using a set of credentials to log into the network
>  also generates an application layer token to use for signing into 
> services - without the need to re-authenticate.

It may also be interesting to look at how network-layer mobility fits
the authentication aspects you're dealing with.  For example, if a
eduroam user uses Mobile IP to maintain ongoing sessions between
different campuses (maybe traveling through UMTS in between).  This can
be achieved by modifying the network layer only (Mobile IP) instead of
going up to the application layer, having thus some advantages.
However, the authentication problems are also raised, for example: what
does the user authenticate - her Home Address or her Care-of Address?
Or both?

Just some thoughts on mobility and authentication.  Thanks for your mail,

Alex

> 
> I realise that some of the points above may not fit perfectly into 
> the IETF scope, either interfacing downwards to layer 2 and IEEE work
>  (EAPoL) or upwards to the application layer. Still, these are points
>  not tackled sufficiently so far and they at least have partial 
> relevance to the IETF work, so I hope that there are some folks out 
> there to discuss this over a beer or two, in a "bar BoF" style.
> 
> Greetings,
> 
> Stefan Winter
> 
> [1] http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> _______________________________________________ IETF mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Stefan Winter <[email-masked]>
Date: Fri, 29 Feb 2008 10:14:27 +0100

Hello!

My name is Stefan Winter of the National Research and Education Network in 
Luxembourg, RESTENA. We are an ISP for academia and take the lead in research 
and development of a global academic wireless LAN federated roaming 
consortium: "eduroam". This is based on EAP and 802.1X exclusively.

In the course of development, prototyping and rollout of eduroam, we have 
discovered that some areas of the relevant standards required some tweaking 
or workarounds. After following IETF work for some time, we also saw that 
some of the efforts exclude roaming use cases from their agenda.

So far I've heard that we are by far the biggest federated 802.1X roaming 
consortium at all, and I wonder if we are the only ones seeing some items 
that could use a second thought when considering roaming between independent 
administrative domains.

I will be at IETF71, and would like to invite anyone who is interested in 
federated roaming scenarios for an informal get-together to exchange ideas. I 
was planning to do this on Monday evening, at a location that is still TBD, 
I'll follow up. 

Below I've put together the most prominent items that are on our radar right 
now to give you a glimpse of the issues we in eduroam are dealing with.

The most prominent issue is the uneasy fact that RADIUS doesn't provide a 
reliable transport and only basic security, while Diameter has no 
implementations and NAS support in the wireless LAN area. With an EAP 
conversation requiring multiple, usually around eight, roundtrips, and a 
packet path that may literally span the whole world, this is a major concern. 
It also didn't particularly help that in a recent discussion on dime, it was 
stated that Diameter doesn't offer significant advances regarding roaming 
compared to RADIUS. 
We tried to mitigate this by proposing RadSec, RADIUS over TCP+TLS [1], and 
are pursuing this in the radext wg right now.

Another thing is that we have no sufficient signalling mechanism to reach the 
end user if the 802.1X login couldn't be completed because of an intermediary 
RADIUS proxy being down - due to the lack of possibility to provide error 
messages in the 802.1X protocol, most supplicants provide the unhelpful 
advice that "Probably the password is wrong", which is wrong and generates 
user frustration. Some kind of "hijacking" the EAP conversation by the last 
responsive proxy to inject EAP-Notifications would be needed probably, but 
this is not thought through in its entirety yet. I'm aware that there is a 
security argument: not disclosing the reason for a failure may make attacks 
more difficult, but still: it would then be desirable to at least have the 
*option* of providing the info - right now it is impossible.

Then, encapsulating EAP in RADIUS may sometimes lead to RADIUS packets being 
so big that they have to be fragmented - not a conceptual problem, but a 
practical one, because out-of-order fragements, or even even in-order UDP 
fragments generate problems on unclever firewalls more often than not. 
Especially EAP-TLS, where both server and supplicant need to send large 
amounts of (certificate) data turned out to be a real challenge. A draft 
about that problem and a sketch of a possible solution is in the works.

Another thing that bugged us about RADIUS is the inability to contact new auth 
servers "on the fly", for example when a new user realm is observed. So far, 
we stacked together RADIUS servers in a realm-based aggregation hierarchy. A 
better approach, in combination with the TCP+TLS nature of RadSec, would be 
to use a dynamic lookup mechanism (e.g. DNS NAPTR/SRV) that allows to 
discover the authoritative home server for a user's realm and to verify that 
server's eligibility by examining the certificate. This is a concept we will 
try out in semi-production use in eduroam soon, but it may have implications 
also out of the eduroam community, since it will allow arbitrary service 
providers to create an authentication fabric very easily on the technical 
side - making the *paperwork* of bootstrapping a roaming consortium the only 
big challenge.

We have been looking at the work of the NEA wg with a bit of concern, since 
its charter excludes the federated roaming case deliberately. For example, 
putting posture information into EAP will always convey the posture info to 
the home server, while it is the service provider that needs the posture 
information to make its admission decision. We understand though that there 
is work going on to make the use of NEA roaming-agnostic, which we would very 
much like to see.

Finally, there is a more exotic area in connection to roaming scenarios: 
converging roaming on the network layer (802.1X+EAP) with Single-Sign On on 
the application layer (SAML et al), with the ultimate goal that using a set 
of credentials to log into the network also generates an application layer 
token to use for signing into services - without the need to re-authenticate.

I realise that some of the points above may not fit perfectly into the IETF 
scope, either interfacing downwards to layer 2 and IEEE work (EAPoL) or 
upwards to the application layer. Still, these are points not tackled 
sufficiently so far and they at least have partial relevance to the IETF 
work, so I hope that there are some folks out there to discuss this over a 
beer or two, in a "bar BoF" style.

Greetings,

Stefan Winter

-- 
Stefan WINTER

RESTENA Foundation - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche
R&D Engineer

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
email: [email-masked]     Tel.:     +352 424409-1
http://www.restena.lu               Fax:      +352 422473
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Stefan Winter <[email-masked]>
Date: Fri, 7 Mar 2008 08:25:56 +0100

Hi Alexandru,

> does the user authenticate - her Home Address or her Care-of Address?

This is indeed another challenge we ran into in eduroam, and it comes even 
without Mobile IP: when authenticating with 802.1X, a layer 2 address is 
authenticated. The later provisioning of a layer 3 address is not tied into 
the authentication at all.
However, if a user commits undesired action, he will be seen on the internet 
with the layer 3 address, which in turn needs to be tracked back to a user 
identity on layer 2.

We have been struggling with this issue for quite a while. There are numerous, 
but incomplete, approaches to that so far. I'll list them for reference, but 
it would sure be very interesting having a chat about improving the l2-to-l3 
binding of a user...

* ARP sniffing: some Access Points keep track of their ARP chaches and look 
which address is using which IP address. Even if a malicious user changes his 
IP address after 802.1X authentication, it will be detected and his identity 
remains known under the new IP address. Drawback: requires vendor support, 
currently only implemented in IPv4.

* DHCP logging: the IP addresses which are handed out can be logged and 
correlated to a layer 2 address. This works on every decent DHCP server. 
Drawback: users can change IP addresses manually later, which is not 
detectable with this method.

* DHCP logging+firewall locks: some participants in eduroam go to great 
lengths: they issue IP addresses with DHCP *and* lock all currently unleased 
IP addresses so that a change of IP address by a malicious user will either 
be caught by the firewall or lead to a clash and thereby disturb connectivity 
for him. Drawback: the approach is quite sophisticated and depends on a 
seamless interaction between DHCP and firewall equipment.

Mobile IP, and the fact that with IPv6, it is normal for a device to have 
multiple IP addresses, add another few facets to the mix.

I'm looking forward to have a chat about that!

Greetings,

Stefan Winter

-- 
Stefan WINTER

Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche
Ingenieur Forschung & Entwicklung

E-Mail: [email-masked]     Tel.:     +352 424409-1

---

From: Stefan Winter <[email-masked]>
Date: Fri, 7 Mar 2008 14:49:40 +0100

Hi guys,

> Another approach that I have been considering would be to implement
> DHCP-snooping on APs or Controllers!
> Cisco already does that for switches.
> (but enabling it on an AP switch-port would break connectivity for all
> users on that AP! This functionality needs to be moved to the AP. Moving
> it to the router leaves the entire layer2 domain unprotected)
>
> A host can generate traffic through an AP only if a DHCP lease has been
> detected for that hardware address.
> Logging will still be the principal tool for correlation. DHCP-snooping
> would alleviate the need for firewall locks. No manual IP addressing
> would be permitted.

What you and the others in the thread say is a good way to this currently (and 
maybe one or another vendor will take it further?). 

I just consider the necessity to apply vendor-specific (or 
bash/iptables-script) "hacks" a conceptual shortcoming. If we'd ever get the 
chance to get a *proper*, standardised way of doing it, the job of 802.1X 
administration would get a lot easier.

NB: how do the DHCP snooping methods perform with IPv6? There is not 
necessarily a stateful DHCPv6 address lease to observe...

I don't think this problem can really be stamped "solved". "worked-around", 
maybe.

Stefan

-- 
Stefan WINTER

---

From: Alan DeKok <[email-masked]>
Date: Fri, 07 Mar 2008 15:43:00 +0100

> administration would get a lot easier.

  I think people won't like this solution, but it makes a certain amount
of sense on a *technical* level:  move IP address assignment into
802.1x.   Many EAP methods that are TLS-based provide for transporting
information inside of the TLS tunnel.  So... transport IP's.

  There are large benefits to doing this.  The client gets assigned an
IP from a known and trusted source (the AAA server he's authenticating
to).  The NAS gets an IP from a known and trusted source (the local AAA
server).  Everyone is happy.

  e.g.

  supplicant      NAS      AAA server
    --------------->                   Can I gain access?
                   ---------->         Permit user on the net?
             <----EAP--->              Lots of packets...
                   <------------       AAA:  "IP 192.0.2.10"
    <----------------------------      TLS tunnel: "IP 192.0.2.10"
    <-------------->                   Surfs the net...

  In a roaming environment, it's just as easy.  The local AAA server
sends the home AAA server the IP it wants to allocate to the user, and
the home AAA server puts that into the TLS tunnel:

  supplicant      NAS      Local      home AAA
    --------------->                         Can I gain access?
                   ---------->               Permit user on the net?
                             ----------->    Please assign IP 192.0.2.10
                             <-----------    ACK's the IP 192.0.2.10
                  <----EAP--->               Lots of packets...
                   <---------                AAA "IP 192.0.2.10"
    <-----------------------------------     TLS tunnel: "IP 192.0.2.10"
    <-------------->                         Surfs the net...

  All IP's are assigned via authenticated and secured transports.  If
TTLS is used, much of this could be done as vendor extensions to a
supplicant.  Maybe some extra effort would be needed on a NAS to permit
IP address assignment for LAN's via DHCP, but not much else.

  This doesn't solve the problem of a user changing their IP later, but
enforcing MAC to IP address mapping is really a job for the NAS.

  Comments?  Sticks and stones?

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 7 Mar 2008 16:16:23 +0100

Hi,

> server).  Everyone is happy.

An interesting thought.

>   Comments?  Sticks and stones?

Poking it with a stick.

First, there is lots of precedence for assigning IPs from AAA of course. 
Framed-IP-Address and friends are used happily in PPP. It leads to a question 
though: with DHCP, more information than just the IP address is transmitted. 
Default GW, DNS, maybe WINS-servers, you name it. So a concept like the one 
you pictured requires duplicating all of DHCP within EAP methods if it is 
supposed to completely replace DHCP.
Also, backwards compatibility comes into play when local AAA tries to send its 
attributes of choice to home AAA and that one doesn't have the capabilities 
for EAP. Some fallback mechanism would be needed, and one that makes sure 
both mechanisms don't assign the same IP inadvertantly. Database-backed DHCP 
and sth like your own products "sqlippool" come to mind.

Policy-wise, are people happy with transmitting their, say, WINS servers from 
local to home AAA or do they consider that not-your-business details? I 
honestly don't know. They happily tell it their clients with DHCP after all.

Hm, actually, most of the things transmitted with DHCP exist in an attribute 
for RADIUS already, probably mostly because of its PPP usage. So the 
local-to-home way might not be so difficult after all.

Greetings,

Stefan

-- 
Stefan WINTER

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 7 Mar 2008 07:20:38 -0800

>   Comments?  Sticks and stones?

See RFC 4014.  This allows the RADIUS server to recommend a pool of addresses
(Framed-Pool or Framed-IPv6-Pool) from which the user address will be chosen.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 07 Mar 2008 16:40:57 +0100

> (Framed-Pool or Framed-IPv6-Pool) from which the user address will be

  While useful, this doesn't let the supplicant know which IP has been
allocated to him.

  The AAA server should be able to send the supplicant a per-session
DHCP signing key, for use in RFC 3118 DHCP packet signing attributes.
That key can also be sent to the local AAA server via AAA, for
distribution to the local DHCP server.  A similar key could be
distributed to the NAS for RFC 4014 purposes.

  That method preserves the existing semantics of DHCP in networks, but
requires coordination between DHCP and AAA servers for key distribution.
    It is likely to be easier to upgrade central DHCP / AAA servers than
to upgrade.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 07 Mar 2008 16:47:42 +0100

> Poking it with a stick.

  This isn't much more than an email discussion.  Don't expect it to be
robust.

> for EAP.

  See the ACK in my diagram.  No ACK from the home server, no signed IP
address assignment.

> Some fallback mechanism would be needed, and one that makes sure 

  Having one centralized authority for IP address assignment is always
useful.

> honestly don't know. They happily tell it their clients with DHCP after all.

  Some people will likely not like that part of it.

> local-to-home way might not be so difficult after all.

  It may be simpler to just distribute keys in AAA, and leverage RFC
3118 for signing DHCP packets.  Again, this is just off-the-cuff discussion.

  Alan DeKok.

---

From: Stig Venaas <[email-masked]>
Date: Fri, 07 Mar 2008 19:10:21 +0100

> Stefan Winter wrote:
[...]
> 3118 for signing DHCP packets.  Again, this is just off-the-cuff discussion.

Right, this is the better approach IMO. This would allow for securely
obtaining various configuration without having to extend RADIUS. There
is hardly any deployment of 3118 AFAIK, but this would be a good use.

This is off-the-cuff as well though, requires some thought.

Stig

---

From: Tomasz Wolniewicz <[email-masked]>
Date: Fri, 07 Mar 2008 08:35:59 +0100

> seamless interaction between DHCP and firewall equipment.
We do exactly this (opening access only for pairs MAC+IP) using a 
dedicated Linux box which serves both as the DHCP server and a firewall 
for the wireless network.
This works quite fine.
Tomasz

-- 
Tomasz Wolniewicz    
          [email-masked]        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: +48-56-611-2750     fax: +48-56-622-1850       tel kom.: +48-693-032-576

---

From: Philippe Hanset <[email-masked]>
Date: Fri, 7 Mar 2008 09:54:01 -0500 (EST)

Well,

Anything that we will come up with is a "hack" to the fact that Hardware
addresses should be unique and stay unique (to the average person!)
So, where do we start the long term planning?

It seems that layer3 should be used for Path Determination, and layer2
for Identification. But I may be outdated!

By fixing layer2 (is it possible considering the amount of cards out
there?) we wouldn't have to worry about IPv4, v6, v...

Now, once the IP-spoofer is detected...how do you disconnect it?
We disable the account and filter the MAC to force a re-auth that will
fail. Can we add "disconnect" on the wish list (or have I missed a chapter
in new 802.1x developments).

Best,

Philippe

----------------------------------
Philippe Hanset
University of Tennessee, Knoxville
Office of Information Technology
Network Services
108 James D Hoskins Library
1400 Cumberland Ave
Knoxville, TN 37996
Tel: 1-865-9746555
----------------------------------

---

From: Philippe Hanset <[email-masked]>
Date: Fri, 7 Mar 2008 08:33:01 -0500 (EST)

Stefan,

Philippe
Univ. of Tennessee

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 8 Mar 2008 06:55:31 -0800

> in new 802.1x developments).

IEEE 802.1X is owned by IEEE 802.1, and is currently undergoing a revision
(IEEE 802.1af) there.  For details, see:
http://www.ieee802.org/1/pages/802.1af.html

With respect to "disconnect" in RADIUS, RFC 5176 describes how 
Dynamic Authorization (including Change-of-Authorization and 
Disconnect) operates within RADIUS.   Several IEEE 802.11 
Access Points now support this.

---

From: "Josh Howlett" <[email-masked]>
Date: Mon, 10 Mar 2008 09:36:54 -0000

This issue is an artefact of the lack of a binding between the link and network addresses and the authenticated EAP Identity.

The obvious place to establish the binding is at the access device, particularly given the possibilities offered by access devices supporting 802.1ae & af.

The various vendor-specific DHCP-snooping stuff is a good start, some standardisation here would be useful though.

josh. 

> -----Original Message-----
> From: Philippe Hanset [mailto:[email-masked]] 
> Sent: 07 March 2008 13:33
> To: Stefan Winter
> Cc: GN2-JRA5; Alexandru Petrescu; [email-masked]; 
> [email-masked]
> Subject: Re: [mobility] Re: Discussion about Federated Roaming
> 
> Stefan,
> 
> Another approach that I have been considering would be to 
> implement DHCP-snooping on APs or Controllers!
> (but enabling it on an AP switch-port would break 
> connectivity for all users on that AP! This functionality 
> needs to be moved to the AP. Moving it to the router leaves 
> the entire layer2 domain unprotected)
> 
> A host can generate traffic through an AP only if a DHCP 
> lease has been detected for that hardware address.
> Logging will still be the principal tool for correlation. 
> DHCP-snooping would alleviate the need for firewall locks. No 
> manual IP addressing would be permitted.
> 
> Philippe
> Univ. of Tennessee
> 
> > * DHCP logging: the IP addresses which are handed out can be logged 
> > and correlated to a layer 2 address. This works on every 
> decent DHCP server.
> > lengths: they issue IP addresses with DHCP *and* lock all currently 
> > unleased IP addresses so that a change of IP address by a malicious 
> > user will either be caught by the firewall or lead to a clash and 
> > thereby disturb connectivity for him. Drawback: the 
> approach is quite 
> > sophisticated and depends on a seamless interaction between 
> DHCP and firewall equipment.
> >
> > Mobile IP, and the fact that with IPv6, it is normal for a 
> device to 
> > have multiple IP addresses, add another few facets to the mix.
> >
> > Stiftung RESTENA - Réseau Téléinformatique de l'Education 
> Nationale et 
> > de la Recherche Ingenieur Forschung & Entwicklung
> >

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG