Subject: [ntpwg] MS-SNTP

From: "David L. Mills" <[email-masked]>
Date: Thu, 27 Mar 2008 00:36:34 +0000

Guys,

I'm sending this to both hackers and the WG, but maybe it should go to 
only one. Your preferences would be cherished.

There has been a lot of discussion on NTP bugs about MS-SNTP, 
Microsoft's extension to NTP for symmetric key cryptography, as well as 
a generic model to rethink the reference implemention key management 
services. I took a look at the MS_SNTP spec, which is even more dreary 
than an IETF spec, and came up with the following observations:

1. The intent in the NTPv4 specification is to use the NTPv3 defined 
cryptographic provisions, but substitute MD5 for DES-CBC. The NTPv4 spec 
explicitly calls out the protocol processing steps for both the server 
and client. If an SNTP client implements authentication in some form, it 
must be compatible with NTPv4.

2. The NTPv4 spec requires the client to generate the MAC, which the 
server checks. This is consistent with symmetric modes and and makes a 
cleaner spec. The MS-SNTP spec requires the client to supply only the 
key ID and not to provide the MAC. An MS-SNTP client would provoke a 
CRYPTO-NAK from an NTPv4 server and interpret this as an authentication 
failure. It would be simple to add an enable/disable flag to require/not 
require the client to generate a MAC. If not required, MS-SNTP clients 
could use NTPv4 servers.

3. Another problem is that MS-SNTP and NTPv4 interpret the key ID field 
in quite different ways. MS-SNTP constructs the key ID from a one-bit 
key selector concatenated with a 31-bit private value based on domain 
and machine identifiers. In general, this exhausts the key ID space. 
However, Autokey uses a pivot point of 65535 and below for symetric keys 
and above for public key IDs. Autokey generates pseudo-random key ID 
streams by MD5 hashes including key IDs where the streams have no 
collisions and hashes always greater than the pivot. Thus, the collision 
probability is close to 2^32 - 2^16, which is negligible.

4. It could be, as previously suggested, to provide a different pivot 
point or another pivot point that would support some combination of 
symmetric key, MS-SNTP key and Autokey, but the problem is that would 
make the hash collisions much more frequent and still not provide 
sufficient floor space for the MS-SNTP key ID.

5. On close inspection it is possible to increase the key ID from 32 to 
64 bits and still keep the extension field parser happy. It is even not 
too hard to have this be transparent to all except the library that 
handles the key management. Presumably, that library could use the two 
words in any way they wish and in principle the selection of each 
library could be on an association specific basis.

6. The only requirement, if more than one cryptographic library is 
involved, there has to be a way to determine which one. Presumably, if 
32-bit key IDs are used, the default is the current interpretation. If 
64-bit key IDs are used, at least some of the bits must be used to 
determine which one. This is most important fot a stateless server which 
has no clue other than the arriving packet.

7. A couple of suggestions on the library interface have been floated on 
the bugs list. If serious, they should be floated here. However, one of 
the things not evident in the suggestions is that some keys have a 
defined lifetime and must be automatically deleted when the lifetime has 
expired. What this seems to mean is a call, once per second or once per 
minute, to a library function.

Dave

3.

3.
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "David L. Mills" <[email-masked]>
Date: Thu, 27 Mar 2008 18:50:46 +0000

Andrew,

Gawd, I have enough trouble with the IETF to go boil in some other 
standards ocean.

Somewhen on the bugs list I was told th key ID would be a hash of the 
RID with possibly the top bit stolen for the key selector. The key 
selector is used to select which of two preloaded keys to use and s 
small state machine used to remember the last selected by the server.

The authentication methods have been specified in all RFCs beginning 
with rfc 1305, but the actual protocol has not. Only in the NTPv4 spec 
has the protocol been specified, including the requirement that the 
client produce a message digest. The simple way forward without messing 
up Microsoft or for that matter any other SNTP client that might not 
expect to provide a MAC, is to make it optional. If the client does not 
provide a MAC, set the digest field to zero.

The other issue is how to farm the key ID space. If there is a drop in 
crypto library for both the existing key management and some other, 
selection of which one, and the key ID farm, could be based on 32/64-bit 
key ID and/or NTP version.

Dave

Andrew Bartlett wrote:

> On Thu, 2008-03-27 at 00:36 +0000, David L. Mills wrote:
>
>> Guys,
>>
>> than an IETF spec,
> BTW, if you want to force Microsoft to improve their spec, you can
> either make comment in their forums
> (http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=573&SiteID=1, 
> or you can join the Protocol Freedom Information Foundation 
> (www.protocolfreedom.org), and use the PFIF's contact with MS and it's 
> formal, enforceable, 'clarification request' process.
>
>> and came up with the following observations:
>>
> I'm a bit unclear on this - I would expect that most (but not all) RIDs
> used by Microsoft clients would be in the range 0-65535, as they are
> generally allocated from a base of 500.
>
> I never quite expected that deployments would enable both authentication
> mechanisms at once, but this seems like a reasonable way forward.
>
> Andrew Bartlett
>

---

From: Andrew Bartlett <[email-masked]>
Date: Thu, 27 Mar 2008 16:15:08 +1100

BTW, if you want to force Microsoft to improve their spec, you can
either make comment in their forums
(http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=573&SiteID=1, or you can join the Protocol Freedom Information Foundation (www.protocolfreedom.org), and use the PFIF's contact with MS and it's formal, enforceable, 'clarification request' process.  

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Luke Howard <[email-masked]>
Date: Thu, 27 Mar 2008 16:17:29 +1100

Don't forget that, for both Novell and Samba, interoperability with  
the existing deployed Microsoft implementation is important.

-- Luke

---

From: Andrew Bartlett <[email-masked]>
Date: Fri, 28 Mar 2008 08:51:00 +1100

> Gawd, I have enough trouble with the IETF to go boil in some other 

The beauty of the WSPP process is that we have purchased the right to
make Microsoft boil the ocean until our satisfaction :-).  But yes, it
takes time and effort. 

> small state machine used to remember the last selected by the server.

The RID is not hashed.  The 'key selector' is because each RID has an
old and new password, and a number of similar protocols in this area
permit use of the old password, to cope with replication delays. 

Andrew Bartlett

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 28 Mar 2008 03:55:10 +0000

Andrew,

Yes, the key select is clever. The orignal NTP design anticipated 
password/key ID change by providing possibly several keys with 
respective key IDs. The client uses the active key ID until the server 
switches to another now active key ID. The client notices this and 
switches to that key ID.

You bring up a most interesting point. My fear is a violent trainwreck 
between the Autokey key space and what I have been told the MS-SNTP key 
space. Because on Autokey pseudo-random key generation and hash chains, 
shrinking the key ID space much would create crippling collisions. On 
the other hand, I understand the RID space is in the order of 500, which 
is far below the symmetric key pivot of 65535. If the MS-SNTP key ID 
space could fit below the pivot, that problem would disappear 
completely. On the other hand, MS-SNTP key space might work if the pivot 
point were increased from 2^16 to 2^18.

Here's a really serious showstopper. Is the gang sweating the runup to 
the last call willing to wait while we shake out these issues? Assuming 
this can be done relatively quickly, I would advise it be so. Here are a 
couple of things that might make it easier.

1. Change the spec to allow the client to opt-out of the requirement to 
construct a MAC. That would be indicated if the client message digest 
was all zeros. This is a no-brainer and should have been anticipated. 
This can be done in the current reference implemenation with two lines 
of code.

2. Resolve whether to activate my suggestion of optional 32/64-bit key 
IDs. WATCH OUT: We now do have the option of incorporating 160-bit 
message digests (SHA_x). Activating 64-bit key IDs prohibits that 
option. If we choose to reject 64-bit key IDs and embrace the 160-bit 
option, that should be so stated in the spec.

3. Resolve the issues on how MS-SNTP and Autokey can cohabit the same 
carcass; however, this must be done without requiring the server to 
retain state.

Dave

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 28 Mar 2008 18:03:16 +0000

Andrew,

I have no idea why MS-SNTP assumes little-endian. All past and present 
IETF protocols assume network byte order, which is big-endian. I find it 
highly surprising that the authors of the MS-SNTP spec apparently did 
not know that. The timestamps and other data in the NTP header, 
including the key ID and message digest, are in big-endian order.

If as presumed the RIDs are small numbers, they would appear in the high 
order bit positions of the NTP key ID and break any possibility for 
coexisence with Autokey. It would not be possible for an NTP server to 
distinguish between MS-SNTP and Autokey and a server could not do both. 
If the endian was corrected and the RIDs or hashes of them could be 
limitied to 16 low-opder bits, coexistence is possible and practical.

The Autokey module was carefully crafted to be replaceable by another 
module with different functions, so in principle MS-SNTP coult be 
supported without gross invasion of the existing code. However, if these 
functions did not include the existing symmetric key ID and keys file, 
the modified server would be useful only to Microsoft clients and could 
not serve as an authenticated client of existing NTP servers.

Still anothere consideration is that both Canadian and NIST servers now 
support NTP symmetric key cryptography. It would be highly ironic if 
MS-SNTP clients could not use those servers.

Dave

Andrew Bartlett wrote:

> On Fri, 2008-03-28 at 03:55 +0000, David L. Mills wrote:
>
>> Andrew,
>>
>> the other hand, I understand the RID space is in the order of 500
>
>
> Values would start at 500, and increase to around the number of users
> and computers in your domain/organisation.
>
>> , which
> Remember that the high bit may or may not be set, and it is in little
> endian. This would seem to preclude any use of a pivot.
>
> What endian does the standard signing mech expect?
>
> Perhaps I'm missing something, but surely if the client has set an
> all-zero checksum, then it's key ID is a MS-SNTP key, while if it has
> specified a checksum, then things fall back to whatever the RFC process
> specifies.
>
> If not, could this be done outside the standards space, on the basis
> that servers wishing to participate in both Microsoft's bastard signing
> scheme - useful *only* on an AD-like domain controller - and proper,
> internet standard NTP signing would be mutually exclusive?
>
> In any case, perhaps we are taking the wrong approach here. I think we
> need to validate actual, not spec, behaviours, and ensure that
> assumptions we are making are real. I think this might all make more
> sense with a patch, and I'll try and work on that soon.
>
> Andrew Bartlett
>

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 28 Mar 2008 18:43:10 +0000

Luke,

Note the pivot partions on the basis of value, not assigned bit fields. 
This is done specificatlly to give Autokey a large fraction of the 
space. Walling of the space seperately by fields would defeat that purpose.

I don't understand your comment about zero and endian. A little endian 
zero is identical to a big endian zero.

Dave

Luke Howard wrote:

> Yes, but because of endian-ness issues, MS-SNTP key 0 is actually  
> 2^32-1.
>
> My original patch supported configurable partitioning of key space.
>
> -- Luke
>
>
> -- 
> www.padl.com | www.fghr.net
>

---

From: "TS Glassey" <[email-masked]>
Date: Sat, 29 Mar 2008 07:10:39 -0700

----- Original Message ----- 
From: "Luke Howard" <[email-masked]>
To: "David L. Mills" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 26, 2008 10:17 PM
Subject: Re: [ntp:hackers] MS-SNTP

> the existing deployed Microsoft implementation is important.

No its not - what is important is to get a fully blown NTP service 
integrated into ALL Microsoft SW platforms.  Microsoft's arrogance to refuse 
to bring their OS's into the same league as the *ix platforms is not the 
WG's problem.

If you want to build a commercial-only service which is specific to 
Microsoft, then build something that works from an audit perspective.

Todd Glassey

> hackers mailing list
> [email-masked]
> https://lists.ntp.org/mailman/listinfo/hackers

---

From: "TS Glassey" <[email-masked]>
Date: Sat, 29 Mar 2008 07:14:13 -0700

I agree that Key Select is important but CSP's are also important so rather 
than building a system specific to the proprietary MS keys', we should build 
one which is capable of taking any key-system.

Todd Glassey

---

From: "David L. Mills" <[email-masked]>
Date: Sat, 29 Mar 2008 17:48:03 +0000

Andrew,

The problem is a stateless server used by clients including Microsoft 
and non-Microsoft key management. The only information available to 
distinguish between the various flavors is the NTP packet itself, in 
particular the key ID. The current MS-SNTP design with, as I have been 
told is hashed RID, completely takes over the key ID space, so would 
preclude operation with non-Microsoft clients. This may well be the 
explicit intent of the design, but it does preclude interoperation with 
national standards laboratories and the existing symmetric key 
infrastructure.

I did a bit of checking and found the MS-SNTP client message with empty 
digest does not work with either NTPv3 or NTPv4 reference 
implementations. A whisker-close reading of the v3 and v4 specs does not 
prohibit an empty digest, but either implementation would treat that as 
an authentication failure. In fact, provisions for this are not hard to 
do, but the NTPv4 spec would have to say exactly how to deal with it.

This is quickly becoming a failed mission. If Microsoft insists on 
propagating MS-SNTP, they should provide their own infrastructure 
independent of the existing NTP infrastructure. I would very much like 
to see the existing key management system overhauled as proposed, but 
only if it can be configured to support the present model based on local 
files. I would expect the server to support authenticated MS-SNTP 
clients or current clients, but not both in the same machine. It also 
means a MS-SNTP server or client cannot be an authenticated client of a 
standards laboratory in the US or Canada and very likely other countries.

Dave

Andrew Bartlett wrote:

> On Fri, 2008-03-28 at 18:03 +0000, David L. Mills wrote:
>
>> Andrew,
>>
> Microsoft does this. Often... Welcome to my nightmare :-)
>
> If that is the cost, it's fine by me. But surely the server could tell
> when it is being a server and when it is being a client?
>
> Andrew Bartlett

---

From: "David L. Mills" <[email-masked]>
Date: Sat, 29 Mar 2008 17:50:34 +0000

Luke,

Can you confirm that the RID is hashed and that the hash can take up to 
31 bits?

Dave

Luke Howard wrote:

>
> On 29/03/2008, at 5:43 AM, David L. Mills wrote:
>
>> Luke,
>>
> My bad. Let me rephrase: Microsoft's encoding of RIDs as key IDs is 
> in  the incorrect byte order.
>
> I can confirm this from my experience building an implementation of  
> this.
>
> -- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 28 Mar 2008 15:06:33 +1100

-- Luke

---

From: Andrew Bartlett <[email-masked]>
Date: Fri, 28 Mar 2008 16:13:29 +1100

Andrew Bartlett

---

From: Andrew Bartlett <[email-masked]>
Date: Sat, 29 Mar 2008 09:21:30 +1100

Andrew Bartlett

---

From: Luke Howard <[email-masked]>
Date: Sat, 29 Mar 2008 11:12:12 +1100

> zero is identical to a big endian zero.

My bad. Let me rephrase: Microsoft's encoding of RIDs as key IDs is in  
the incorrect byte order.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sun, 30 Mar 2008 10:36:12 +1100

Dave,

The RID is not hashed, it's an integer that is roughly analogous to a  
UID or GID on POSIX systems. In an NTP packet, it is encoded in the  
incorrect byte order.

The size of the RID space depends on the number of users in a domain;  
the first RID is typically 500, as Andrew points out.

It appears that the most significant bit is used to select between the  
current and prior shared secret (although I wasn't aware of this when  
I built Novell's implementation).

regards,

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sun, 30 Mar 2008 10:44:52 +1100

On 30/03/2008, at 1:10 AM, TS Glassey wrote:
>
> ----- Original Message ----- From: "Luke Howard" <[email-masked]>
> integrated into ALL Microsoft SW platforms.  Microsoft's arrogance  
> to refuse to bring their OS's into the same league as the *ix  
> platforms is not the WG's problem.

I meant "what is important to Novell and Samba", not "what is  
important to the WG". Of course, the WG mailing list is probably not  
the appropriate forum for discussing the former :-)

-- Luke

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 31 Mar 2008 07:48:16 -0700

Andrew
I have also proposed a replacement or augmentation to AutoKEY which can use 
a PKCS11/12 type CSP or a CDSA type CSP.

We also have a stored-key system which we are playing with actually stores 
the keys in MySQL and uses a S/Key type client interface to make one-time 
keys possible. This makes the capability of the server several hundred 
million keys or more...

Todd

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 31 Mar 2008 07:44:58 -0700

Dave
after your nasty response I decided to send a thank's note to you personally 
and then respond to the list. Try not to get too upset but your responses 
here sound like a whiney 3 year old.

More retort's below...

----- Original Message ----- 
From: "David L. Mills" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Saturday, March 29, 2008 10:48 AM
Subject: Re: [ntpwg] [ntp:hackers] MS-SNTP

> and non-Microsoft key management.

Yes but what is the problem with that? - David  as you said it (SNTP) was 
intented for sychronization of end-node devices or devices where there was 
no need for the type of logging or data capture models that NTP supports. 
But because that was your original intent, doesnt mean that other's cannot 
use it in the form's that Microsoft has.

If Microsoft wants to use a NTP formatted packet specification to move data 
and that interface meets the SNTP interface requirement's per the portions 
of the spec that say "This all must be implemented to meet the NTP or SNTP 
interface specifications", then they can do that - and David - that is the 
fault of that "License for Use" that you made NTP available under...

Oops -   guess you have to blame yourself for this fiasco.

> The only information available to
> particular the key ID.

If Microsoft's implementation is intentionally constrained so that it works 
differently than your "best case" model, then that is their choice. The NTP 
protocol and its license says nothing about how its to be used or how much 
of it must be implemented. by folks using it.

The fix for this is that NTPv4 should address (or perhaps the v5 release) 
should address the creation of a serious set of "practice's Interfaces" 
which support NTPv4 full, SNTPv4. That is

    1)     A set of minimum compliance interface requirement's and process 
steps for

                A)    Unauthenticated SNTP to NTP Setting Events
                B)    Unauthenticated NTP to NTP Setting and Peering Event's
                C)    Authenticated SNTP to NTP Setting Event's
                D)    Authenticated NTP to NTP Setting and Peering Event's
                E)    Payload Time-stamp generation ala Glassey/McNeil 
extension's

    2)    A set of basic characterization of NTP/IP performance metrics in 
loaded environment's. The Benchmarks to produce the loading to support this 
analysis are totally available.  This will create a benchmark itself for 
what Appliance Type and Computer Type NTP Services should produce in the 
form of number of setting's per second/minute and jitter/drift control's for 
those platforms.

> The current MS-SNTP design with, as I have been
> preclude operation with non-Microsoft clients.

So what? - this means that we need to install the Meinberg NTP Service where 
we want to bridge across those time-synch models and practices. Let 
Microsoft do whatever they want...

> This may well be the
> implementations.

So what ???- it obviously wasnt important to Microsoft - why do you think 
that is by the way?

> A whisker-close reading of the v3 and v4 specs does not
> an authentication failure.

Only if the full controls on the protocol are met. The fact that the 
Microsoft port doesnt meet those functionalities proves that this isnt 
necessary. All it does is breaks the NTP reference system, but is that a 
real problem in time-keeping?

> In fact, provisions for this are not hard to

No kidding - I have been saying this for years now - about how what the NTP 
process actually needs are real-world use models and practices but I was 
blow off the list for suggesting that this reality was in fact something 
interesting... That said, what NTP really needs is protocol definitions that 
are easilly implemented as a process. That is to say, a software 
specification for the protocol and its use practices and these MUST have a 
set of bassic performance characteristics.

> independent of the existing NTP infrastructure.

And they could do this easily if there was a good practice model

> I would very much like

---

From: Andrew Bartlett <[email-masked]>
Date: Tue, 01 Apr 2008 10:04:42 +1100

> independent of the existing NTP infrastructure. 

This is not about what Microsoft wants.  Microsoft does not want this to
happen.  Microsoft would be very happy if we get tied up in discussions
like this one, unable to make forward progress.

This is about the Samba team not wishing to re-implement (or
fork-and-embed) ntpd.  It looks like a simple enough protocol, it
shouldn't be to hard, but I really don't want to do that.

I agree, Microsoft has been bastards, and completely stomping on your
protocol.  I'll soon be giving a talk at SambaXP in 2 weeks time
entitled 'the little barber shop of horrors', looking at what they did
to LDAP.

My concern is how to progress Samba4, and our effort to replace
Microsoft's AD domain controller with one running on Linux, for existing
clients, running unmodified client software.  Microsoft's clients will
not run unmodified without this authentication suite, when talking to
what they think is an AD domain controller. 

As I see it, the more we can use existing open source software, and have
our changes included upstream (preferably in a way that users can just
enable a Samba4 quirks mode) the better is is for the open source
software community.

I realise this will not help a mission of leaving Microsoft out in the
cold, but if we can't make this work, the only people it will hurt is
the Samba team, and those trying to reduce their dependence on
Micorsoft's software.  

Andrew Bartlett

---

From: "David L. Mills" <[email-masked]>
Date: Tue, 01 Apr 2008 02:33:40 +0000

Andrew,

I hear you and don't want to leave Microsoft out in any case. As it 
stands, the MS-SNTP key ID scheme is incompatible with ordinary NTP 
users and the national laboratories. But, you have given me an idea.

You say Samba is to simulate an AD controller, which means it would be a 
MS-SNTP server for that domain. I wouldn't thnk the Samba AD would 
ordinarily be a MS-SNTP client of another MS-SNTP server in that 
domaing, but that might happen. On the other hand, the Samba 4 machine 
would very likely be a client of other NTP server(s). This is the case I 
am worried about. An even more perplexing case is when the Samba machine 
is a server for both NTP and MS-SNTP clients.

For grins, I propose a configuration command to set the default server 
key ID scheme (ntp/mssntp/...) plus an association configuration option 
to set the default client key ID scheme. Exceptions can be handled by 
the restrict mechanism by using the restrict bits to override the 
default server scheme. I assume an AD will not have addresses scattered 
all over the place and relatively few address/mask pairs would be 
necessary. If on the other hand only a few NTP clients are used, the 
mask can apply to them.

Does this work?

Dave

---

From: Andrew Bartlett <[email-masked]>
Date: Tue, 01 Apr 2008 13:52:18 +1100

On Tue, 2008-04-01 at 02:33 +0000, David L. Mills wrote:
> MS-SNTP server for that domain. 

Yes. 

> I wouldn't thnk the Samba AD would 
> domaing, but that might happen. 

It could certainly happen.  

> On the other hand, the Samba 4 machine 
> would very likely be a client of other NTP server(s). 

Yes.

> This is the case I 

I think it would.

Thanks,

Andrew Bartlett

---

From: Luke Howard <[email-masked]>
Date: Tue, 1 Apr 2008 14:33:27 +1100

> domaing, but that might happen. On the other hand, the Samba 4 machine

It would happen in larger deployments, because the NTP synchronization  
hierarchy by default mirrors the Windows domain hierarchy.

> necessary. If on the other hand only a few NTP clients are used, the

That sounds like a good approach. The patch I initially submitted  
supported multiple authentication providers for different parts of the  
key ID space, perhaps this could be extended to support client address  
ranges too.

-- Luke

---

From: "TS Glassey" <[email-masked]>
Date: Tue, 1 Apr 2008 07:07:58 -0700

OK Luke
but this brings up a larger issue, and that is that there are at least two 
other protocols' which will want to be able to use NTP services and that 
number will likely expand. So perhaps rather than just fixing SAMBA why not 
fix NTP so it can be referred to or called by any other protocol.

To that end in addition to SAMBA I would also suggest that the same 
timesetting requirement's are true for NEA and possibly DHCP protocols as 
well and that any solution which is setup to provide NTP services from 
another protocol should also address these other protocols. Likewise DNS and 
DNSSEC tools would be a powerful resource for time-server and time-token 
distribution in AutoKEY or other crypto-environment's

Todd Glassey