Subject: [Nea] Consensus check on EAP-based PT

From: "Susan Thomson (sethomso)" <[email-masked]>
Date: Tue, 2 Aug 2011 16:04:25 -0500

At IETF81 and several prior IETF meetings, as well as on the mailing
list, the WG has evaluated the pros and cons of 2 architectural
approaches to carrying posture within an EAP tunnel method: 

- EAP method 
http://www.ietf.org/internet-drafts/draft-hanna-nea-pt-eap-01.txt

- EAP TLV.
http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt

So far, there has been no WG consensus to adopt one architecture versus
the other. (At the recent F2F meeting in Quebec City, the consensus
check at the meeting showed an equal number in favor of each approach.)

This email is a final call to determine WG consensus on the L2 PT
approach. 

The consensus check is to choose one of the following 3 options:
1) PT-EAP approach
2) NEA-TLV approach
3) Neither (please state the reason if you choose this option)

Please respond to the above question by Tues Aug 16 at 5pm PT. Please do
so even if you have already expressed your opinion, either at a WG
meeting or on the mailing list. The answer can be as brief as selecting
option 1), 2) or 3). If you would like to add your reasons for your
choice, that would be appreciated too, especially if you choose option
3).

If we have consensus on the mailing list, we will adopt the selected
approach.

If we still do not have consensus, the WG chairs and AD (Stephen
Farrell) have agreed that the AD will make a decision. The proponents of
both approaches have agreed to abide by this decision. This resolution
plan was discussed at the F2F meeting at IETF81. This plan was also
communicated to the list in an email on Jun 30, 2011. No objections have
been received.

In either case, the individual submission corresponding to the selected
approach will be adopted as a -00 NEA WG I-D, and we will proceed with
the normal process of editing the document within the WG.

Thanks
Susan

------------------
References:
IETF81 audio session (start at approx 44 mins into session): 
http://www.ietf.org/audio/ietf81/ietf81-2103-20110727-1256-pm.mp3

IETF81 draft meeting minutes:
http://tools.ietf.org/wg/nea/minutes

---

From: Ira McDonald <[email-masked]>
Date: Tue, 2 Aug 2011 17:45:01 -0400

Hi,

Option 1 - PT-EAP

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Chair - TCG Embedded Systems Hardcopy SWG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

On Tue, Aug 2, 2011 at 5:04 PM, Susan Thomson (sethomso) <[email-masked]
> wrote:

> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea
>

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 2 Aug 2011 18:54:02 -0400

<WG Chair Hat Off>

I prefer option 1) PT-EAP.

My reasoning is that PT-EAP has been thoroughly vetted and widely
implemented over the last five years. Also, it provides the best
foundation for important future extensions such as secure proxy,
as highlighted by Stefan Winter's recent comments on the NEA list.

Thanks,

Steve

<WG Chair Hat On>

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Susan Thomson (sethomso)
> Sent: Tuesday, August 02, 2011 5:04 PM
> To: [email-masked]
> Subject: [Nea] Consensus check on EAP-based PT
>

---

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Wed, 3 Aug 2011 00:52:35 +0100

+1.  

My vote is also for approach #1 for same reasons as noted by Steve. 

-Mauricio 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Hanna
Sent: Tuesday, August 02, 2011 3:54 PM
To: [email-masked]
Subject: Re: [Nea] Consensus check on EAP-based PT

<WG Chair Hat Off>

My reasoning is that PT-EAP has been thoroughly vetted and widely implemented over the last five years. Also, it provides the best foundation for important future extensions such as secure proxy, as highlighted by Stefan Winter's recent comments on the NEA list.

Thanks,

Steve

<WG Chair Hat On>

> So far, there has been no WG consensus to adopt one architecture 
> versus the other. (At the recent F2F meeting in Quebec City, the 
> consensus check at the meeting showed an equal number in favor of each 
> approach.)
> 
> Please respond to the above question by Tues Aug 16 at 5pm PT. Please 
> do so even if you have already expressed your opinion, either at a WG 
> meeting or on the mailing list. The answer can be as brief as 
> selecting option 1), 2) or 3). If you would like to add your reasons 
> for your choice, that would be appreciated too, especially if you 
> choose option 3).
> 
> Farrell) have agreed that the AD will make a decision. The proponents 
> of both approaches have agreed to abide by this decision. This 
> resolution plan was discussed at the F2F meeting at IETF81. This plan 
> was also communicated to the list in an email on Jun 30, 2011. No 
> objections have been received.
> 
> In either case, the individual submission corresponding to the 
> selected approach will be adopted as a -00 NEA WG I-D, and we will 
> proceed with the normal process of editing the document within the WG.
> 
> Thanks
> Susan
> 
> ------------------
> References:

---

From: Hao Zhou <[email-masked]>
Date: Tue, 02 Aug 2011 20:08:17 -0400

My choice is NEA-TLV.

---

From: Frank Yeh Jr <[email-masked]>
Date: Tue, 2 Aug 2011 18:59:47 -0700

I support method 1) PT-EAP

Frank Yeh
Sr. Security & Privacy Integration Architect
IBM Security Services

From:       "Susan Thomson (sethomso)" <[email-masked]>
To:         <[email-masked]>
Date:       08/02/2011 02:06 PM
Subject:    [Nea] Consensus check on EAP-based PT
Sent by:    [email-masked]

- EAP method

- EAP TLV.

Thanks
Susan

------------------
References:

---

From: Alan DeKok <[email-masked]>
Date: Tue, 02 Aug 2011 22:26:14 -0400

> My choice is NEA-TLV.

  +1

  My reason is experience has shown that TLVs work (MS SoH, etc.), and
re widely deployed.  Doing another EAP method is more problematic.

  Alan DeKok.

---

From: Andreas Steffen <[email-masked]>
Date: Wed, 03 Aug 2011 07:55:37 +0200

Hi,

my choice is option 1) PT-EAP.

The advantage of using an inner EAP protocol for PT in an IKEv2
context is that within the outer TLS tunnel the initial EAP-Identity
exchange, an ensuing EAP-based client authentication (e.g. EAP-MD5
or EAP-MSCHAPv2) and finally EAP-PT can be handled in a consistent way
by loading the corresponding EAP plugins.

Best regards

Andreas

> the normal process of editing the document within the WG.

======================================================================
Andreas Steffen                         [email-masked]
strongSwan - the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==

---

From: Joe Salowey <[email-masked]>
Date: Tue, 2 Aug 2011 23:50:28 -0700

> as highlighted by Stefan Winter's recent comments on the NEA list.
[Joe] I disagree that the EAP method approach is a good direction to a secure proxy and other extensions.   Currently in RADIUS, EAP is carried directly within a RADIUS attribute with no additional protection.  For modern EAP methods this is not a problem, since they provide sufficient protection from various forms of attack (as they should since they are used on unprotected links).  We have spent a lot of effort moving away from EAP methods such as EAP-GTC and EAP-MD5 that are not strong.  PT-EAP is a step backwards in this regard.  Implementations will now have to be concerned about the protection communications when an EAP attribute is being carried. Alternatively, if TLVs are used a new RADIUS attribute can be defined to proxy the data if necessary.  In addition, this attribute can be designed to provide the protection that is appropriate for NEA data.  

>> do
>> of

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 3 Aug 2011 11:53:34 +0200

Hi,

> 3) Neither (please state the reason if you choose this option)

I support option 2) NEA-TLV

Klaas

---

From: Lisa Lorenzin <[email-masked]>
Date: Wed, 3 Aug 2011 06:14:38 -0700

I support option 1, PT-EAP.

Neither standard seems to be a clear technical leader;
PT-EAP better meets the "running code" goal (more
implementations) and RFC 5209 requirements (based on
an existing open standard).

                                Regards,

                                        Lisa

--
Lisa Lorenzin  /  919-384-7275  /  [email-masked]
Principal Solutions Architect - Security & Mobility
Juniper Networks  /  http://www.juniper.net

---

From: Marc Linsner <[email-masked]>
Date: Wed, 03 Aug 2011 09:33:51 -0400

>3) Neither (please state the reason if you choose this option)

#2

-Marc Linsner-

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 3 Aug 2011 10:28:00 -0400

Joe,

I have changed the subject line since we're pursuing a
different topic now.

We talked about this at length in the WG meeting last week.
I think we all agreed that both of the L2 PT proposals MUST
be carried in an EAP tunnel method or equivalent protection.
This will need to be an explicit requirement in the spec.

The same requirements should apply to proxying PT beyond
the end of the EAP tunnel method. For PT-EAP, the obvious
choice is to use RADSEC (RADIUS/TLS). For EAP-TLV, a new
RADIUS attribute could be created to solve the problem,
as you suggest. Or RADSEC could be used. But neither L2 PT
proposal is suitable for unprotected conveyance over an
untrusted network. I suppose we could revise the proposals
to include their own security measures so that they could
be carried without external protections. But this was never
a design goal for NEA. I don't see any reason to add it
now, especially in the middle of a consensus check.

Thanks,

Steve

> From: Joe Salowey [mailto:[email-masked]]
> Sent: Wednesday, August 03, 2011 2:50 AM
> To: Stephen Hanna
> Cc: [email-masked]
> [Joe] I disagree that the EAP method approach is a good direction to a
> secure proxy and other extensions.   Currently in RADIUS, EAP is
> carried directly within a RADIUS attribute with no additional
> protection.  For modern EAP methods this is not a problem, since they
> provide sufficient protection from various forms of attack (as they
> should since they are used on unprotected links).  We have spent a lot
> of effort moving away from EAP methods such as EAP-GTC and EAP-MD5 that
> are not strong.  PT-EAP is a step backwards in this regard.
> Implementations will now have to be concerned about the protection
> communications when an EAP attribute is being carried. Alternatively,
> if TLVs are used a new RADIUS attribute can be defined to proxy the
> data if necessary.  In addition, this attribute can be designed to
> provide the protection that is appropriate for NEA data.
> 
> > Thanks,
> >
> > Steve
> >
> > <WG Chair Hat On>
> >
> versus
> selecting
> selected

---

From: Mike Fratto <[email-masked]>
Date: Wed, 3 Aug 2011 11:55:08 -0400

Voting for 1) PT-EAP approach and strongly urge that the proposal be
modified to require adequate EAP protections, re: Hanna's suggestion.

---

From: Joe Salowey <[email-masked]>
Date: Wed, 3 Aug 2011 13:55:20 -0700

On Aug 3, 2011, at 7:28 AM, Stephen Hanna wrote:

> the end of the EAP tunnel method.

[Joe] If you follow the above mandate then you would not expose PT-EAP outside the tunnel method.  I believe this is the appropriate requirement if using PT-EAP.  

> For PT-EAP, the obvious
[Joe]  The problem here is that the EAP RADIUS attribute in general does not require additional protection.  PT-EAP introduces a new special case in which it does.  This creates a situation in which implementations need to check the EAP type code in order to change their behavior.    While this may seem harmless, it adds complexity and conspires against the extensible framework that EAP and AAA are built upon.   I agree that there are multiple ways to protect an attribute.  When proxying NEA data as an EAP method you are overloading an existing attribute with new meaning and requirements, but with a TLV you would create a new attribute with its own protection requirements and possibly its own protection mechanism.   You can also create an attribute to carry PT data even if you are using PT-EAP, which would be my preferred approach if we are going to expose NEA data outside the tunnel.

---

From: Joe Salowey <[email-masked]>
Date: Wed, 3 Aug 2011 13:57:06 -0700

I prefer the TLV based approach.   The EAP based approach creates an anomalous EAP method whose behavior must be accommodated for in EAP and AAA implementations as a special case.   While much of the complexity can be hidden within a tunnel method, the tunnel method itself will need to deal with the oddities resulting from trying to fit a method whose goal is not authentication into an authentication framework.   It addition, it seems there is an intention to expose PT-EAP outside the tunnel method, which exposes the special case treatment outside of the tunnel method.  The fact that implementations have worked around some of these issues does not justify creating a standard around these exceptions to the architecture.  

If we do go down the path of PT-EAP then the exceptions to the EAP framework need to be documented, the method should only be allowed within a tunnel method and I think there should be a recommendation against creating more special case EAP methods for other purposes. The later should also be part of the EAP applicability statement update. 

Cheers,

Joe

---

From: Jouni Malinen <[email-masked]>
Date: Thu, 4 Aug 2011 00:27:19 +0300

> 3) Neither (please state the reason if you choose this option)

My preference is 1) PT-EAP approach

Based on my experience working with both EAP-based and TLV-based
extensions for EAP-{TTLS,PEAP,FAST}, the EAP-based design felt cleaner
and simpler to implement and maintain.

-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 3 Aug 2011 20:47:43 -0400

My comments are inline below.

Joe Salowey wrote:
> [Joe] If you follow the above mandate then you would not expose PT-EAP
> outside the tunnel method.  I believe this is the appropriate
> requirement if using PT-EAP.

I don't agree. You should be able to use RADSEC to proxy PT-EAP
from an EAP server that terminates the EAP tunnel and authenticates
the user to a NEA Server that performs the posture assessment.

> [Joe]  The problem here is that the EAP RADIUS attribute in general
> does not require additional protection.  PT-EAP introduces a new
> special case in which it does.  This creates a situation in which
> implementations need to check the EAP type code in order to change
> their behavior.    While this may seem harmless, it adds complexity and
> conspires against the extensible framework that EAP and AAA are built
> upon.   I agree that there are multiple ways to protect an attribute.
> When proxying NEA data as an EAP method you are overloading an existing
> attribute with new meaning and requirements, but with a TLV you would
> create a new attribute with its own protection requirements and
> possibly its own protection mechanism.   You can also create an
> attribute to carry PT data even if you are using PT-EAP, which would be
> my preferred approach if we are going to expose NEA data outside the
> tunnel.

PT-EAP is no more a special case than any of the other EAP methods
that cannot safely be used without protections. You may consider
this to be difficult to implement but several implementers have
already spoken out on the NEA list saying that they found an EAP-
based PT easier to implement than an attribute-based PT. I don't
question that PT-EAP might be harder for your employer to implement
since you've designed your architecture around using TLVs to carry
posture but apparently this does not hold for other implementations.

Thanks,

Steve

> >>>> communicated to the list in an email on Jun 30, 2011. No
> objections
> >>>> have
> >>>> been received.
> >>>>

---

From: Nancy Cam-Winget <[email-masked]>
Date: Wed, 03 Aug 2011 18:26:16 -0700

I prefer the EAP-TLV approach.

While there may be implementations that are close to the EAP-PT proposal,
 there are also similar implementations of the EAP-TLV.

Several EAP-PT issues and concerns were raised that for me, outweigh
 the "benefits of already having code":
 - the goal for NEA is to define a transport for data.  EAP is designed
 and defined to be an authentication framework.  To "only carry data",
 issues for how the design must now accommodate the "no authentication"
 must now be compensated for...  For instance: how does the state machine
 know that the intent is for it to carry NEA data only and not
authentication?
 The two main issues of violations for using an authentication framework
(EAP)
 for not doing authentication is in the generation of an identity and the
 creation of keys. 

 - code and configuration updates are going to be needed regardless of
 whether we adopt EAP-PT or EAP-TLV.  While it may be perceived to "be
simpler" as some vendors allow for ease of adding EAP methods....these
 interfaces were intended to be defined for adding new authentication
 methods, not "methods that only carry data".

 - the above raises one of my security concerns that if we were to allow
 for "lets just add another EAP method", there is the danger that EAP-PT
 can be used as a standalone method which we have discussed as being
 insecure.  As Joe succinctly states, while we can make special cases
 for EAP-PT....but more importantly, I think we are setting a bad precedence
 in defining a "non authenticating" EAP method and opening the door for
 defining other things as EAP methods too.....

   Nancy.

---

From: Joe Salowey <[email-masked]>
Date: Wed, 3 Aug 2011 22:20:56 -0700

On Aug 3, 2011, at 5:47 PM, Stephen Hanna wrote:

> that cannot safely be used without protections.

[Joe] For over 10 years we have been developing EAP methods that do not need extra protection.  Why should we take a step backward with PT-EAP? Methods that do not provide protection should not be used outside a tunnel method, period.  These weak methods are not something we should be trying to promote in the IETF, let alone generate.  If you are going to use a weak EAP method then constrain it to a tunnel.  Standard proxy implementations do not look into the EAP attribute to extract the type to determine how to protect the message.  If you are going to proxy data which is sensitive then it must not be placed in a generic EAP attribute which is proxied without regard for protection.  Instead, place it in its own attribute so implementations can treat it correctly by protecting the attribute or the entire packet.  

> You may consider

[Joe] My concern is not with my implementation and my developers, but rather that you are creating a situation in which a developer or deployer who is not familiar with your deviant use of EAP can introduce security vulnerabilities into their networks.   I understand how tempting it is to try to leverage some of the properties of EAP and AAA as a implementation short cut, however it is often the case that implementation short cuts lead to security vulnerabilities.

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 5 Aug 2011 17:38:03 -0400

Joe,

Neither proposed PT method includes confidentiality or
integrity protection. Both are dependent on an enclosing
tunnel to provide those protections. Everyone has agreed
that we will include explicit language in the final NEA
L2 PT specification, prohibiting sending L2 PT messages
without proper security protections. The risks and
countermeasures here are the same for the two proposals.

You may believe that the risks are greater with an EAP
method but many developers have proxied posture TLVs
over RADIUS without protection. The risk is the same
for both proposals.

I'm fine with prohibiting the use of whatever proposal
we agree on outside a tunnel. I'm just pointing out that
using RADSEC for proxying provides a tunnel also and
there's no rational reason to prohibit that.

Let me try moving on to a constructive suggestion.
Maybe we should consider making our L2 PT safe for
proxying outside a tunnel by adding encryption,
authentication, integrity protection, etc. We could
derive a key from TLS-Unique. This could work for
either of the proposals. And that should address your
concern about defining a new EAP method that's not
safe for use outside a tunnel. It would even make
PT-EAP a true authentication method, although the
identity established would only be "one of the
endpoints for TLS tunnel X."

Thanks,

Steve

> Sent: Thursday, August 04, 2011 1:21 AM
> To: Stephen Hanna
> Cc: [email-masked]
> Subject: Re: Protecting L2 PT when proxying
> 
> 
> [Joe] For over 10 years we have been developing EAP methods that do not
> need extra protection.  Why should we take a step backward with PT-EAP?
> Methods that do not provide protection should not be used outside a
> tunnel method, period.  These weak methods are not something we should
> be trying to promote in the IETF, let alone generate.  If you are going
> to use a weak EAP method then constrain it to a tunnel.  Standard proxy
> implementations do not look into the EAP attribute to extract the type
> to determine how to protect the message.  If you are going to proxy
> data which is sensitive then it must not be placed in a generic EAP
> attribute which is proxied without regard for protection.  Instead,
> place it in its own attribute so implementations can treat it correctly
> by protecting the attribute or the entire packet.
> 
> > You may consider
> [Joe] My concern is not with my implementation and my developers, but
> rather that you are creating a situation in which a developer or
> deployer who is not familiar with your deviant use of EAP can introduce
> security vulnerabilities into their networks.   I understand how
> tempting it is to try to leverage some of the properties of EAP and AAA
> as a implementation short cut, however it is often the case that
> implementation short cuts lead to security vulnerabilities.
> 
> > Thanks,
> >
> > Steve
> >
> >>>> [Joe] I disagree that the EAP method approach is a good direction
> to
> >> a
> >>>>>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >>>> Of
> >>>>>> Susan Thomson (sethomso)
> >>>>>> approach will be adopted as a -00 NEA WG I-D, and we will
> proceed
> >>>> with

---

From: Mike Fratto <[email-masked]>
Date: Sat, 6 Aug 2011 10:21:40 -0400

Steve, I think one, maybe more, PT protection method needs to explicitly
defined as a MUST otherwise you run the risk of conformant but
non-interoperable implementations.

---

From: Joe Salowey <[email-masked]>
Date: Mon, 8 Aug 2011 12:39:00 -0700

> there's no rational reason to prohibit that.

[Joe]  The problem is that the default behavior in proxying EAP attributes is to proxy them unprotected.  We have spent a lot of time developing EAP method that are secure under this behavior.  Now you are introducing a new EAP method with additional protection requirements.  I believe this is a risk given the state of current standards-based deployments.  

> endpoints for TLS tunnel X."

[Joe]  I don't quite follow your proposal, it seems complex to protect data beyond the tunnel using the tunnel.  Here is my suggestion:  

1. Exchange PA data within the EAP tunnel method.   I would prefer this to be in a TLV, but It could be an EAP method if that is the decision.  
2.  When you are transporting the PA data outside the tunnel define a specific AAA attribute to carry it (do not use the EAP attribute).  Make this new attribute an encrypted attribute.  

This way proxies that understand the must explicitly apply protection that is appropriate for the attribute.  A current proxy implementation that does not understand this attribute will just forward encrypted data.  This way we do not have to redefine the behavior of the standard attribute.

---

From: kaushik narayan <[email-masked]>
Date: Mon, 8 Aug 2011 13:32:50 -0700

I prefer EAP TLV method.

I was wondering whether this question should be debated in EMU as well since the question is less
about NEA and more about how to use EAP as a carrier for NEA. EAP-TNC creates an EAP method to  
carry application data (posture is pretty much an opaque data exchange for EAP)  and creates a precedent 
for other EAP methods to defined to carry arbitrary data sets. I would presume the EMU folks might want to
say something about that.

regards,
 kaushik

---

From: Paul Sangster <[email-masked]>
Date: Tue, 9 Aug 2011 09:03:42 -0700

My vote is for PT-EAP.

It's my current view that both proposals are very close functionally and I don't see a compelling reason to select a TLV based approach.  I believe we should follow RFC 5209 which discusses the selection criteria for NEA protocols.  Again both approaches meet most of the requirements, however PT-EAP is already fully documented in a public standards based spec.  If that's not enough, we have a lot of implementation experience with PT-EAP with 9 independent implementations, many plugfests, clarification updates to the original spec (factoring in implementer feedback) and even compliance tests using a test suite specifically designed to test implementations.  Also, I think we should consider the Tao of the IETF in this particularly: 
    "One of the "founding beliefs" is embodied in an early quote about the IETF from David Clark: "We reject kings, 
    presidents and voting. We believe in rough consensus and running code".

On the implementation side, we actually have the OpenSEA Alliance supplicant which supports EAP-TNC carrying PB-TNC and PA-TNC, so we know the stack works well together and the implementers have reported no significant or unusual issues during the development (not even to the EAP engine).

It sounds like the discussion about protection of the inner method (or TLVs) carrying the posture could be addressed by adding security to either proposal.  I've not been convinced this is a serious problem that we can solve with words in a specification, since the root cause seems to be administrator misconfiguration/use of a product potentially resulting in weak security.  Administrator errors are hard to solve in standards specs unless we preclude any compliant product from ever being configured to potentially be not secure.  This is difficult and doesn't allow for deployments where they have addressed the security threats via other countermeasures (e.g. link encryption, proxied EAP over an encrypted link, physical isolation, ...).  I do think we should require implementation of core security features, but requiring their use in all situations is something we would need to discuss more.

---

From: Stephen McCann <[email-masked]>
Date: Fri, 12 Aug 2011 10:23:58 +0100

Dear all,
             my choice is for option 2)

Kind regards

Stephen