Well, you could use LLDP device type to sort out what is and isn't a phone. I'd have to be pretty hard pressed to spoof an Avaya MAC AND tell LLDP I'm a phone and not a computer.
802.1x, if configured to just permit MACs, would let anyone spoof a MAC and be allowed in. So, if you went to the trouble of maintaining all the MACs of all the phones you have, then your NAC wouldn't blanket allow any Avaya MAC in, just the ones you specifically allowed.
You can do 802.1x with EAP without a certificate with some kind of preshared key, or password, or 'name' like 'your mac address' and have it authenticated by a RADIUS server or whatnot.
Or, you can use EAP-TLS, where the phone's certificate request occurs within the 802.1x exchange (look at the authentication workflow on pg 8 of the whitepaper).
Still, this is what jimbo was saying when the phones need to be on an 'open' port. How are you going to make sure the phones have a settings file before they do this? Most of the settings file is retained by the phone through reboots.
So, you could pre-stage the phones in a secure network segment to get a settings file that will tell them to do 802.1x and with EAP-TLS to SCEP their cert in the exchange. Then you could put the phones at desks and they should remember how to do the cert request via SCEP with something like username=$MYMAC and pw=$MYMAC.
At that point, I could have my laptop, spoof an Avaya phone MAC address, but unless I knew what was in the settings file for MYCERTURL, I wouldn't know the key points of being able to do that cert enrollment in the dot1x exchange.
You still have a chicken and egg situation - how do you provide the trusted information to the phones to know to get on the network while restricting that information from a theoretical bad guy who could conceivably pretend to be a phone?
Maybe part of your provisioning looks like this:
-new phone plugs in at desk
-user requests onboarding
-LAN guy disables .1x, puts port in phone provisioning VLAN
-Phone gets DHCP/46xxsettings.txt that tells it how to EAP-TLS/cert enroll
-LAN guy enables .1x on the port
-Phone does it's magic dance and enrolls
The short answer is you're either accounting for everything ahead of time, or your process to manage devices one at a time is going to be long and painful to do moves and changes. I'd suggest testing it out and figure out from your ops managers what the required time would be for each step to ballpark what impact that would have on your operational costs to do day to day administration.
Here's another way to accomplish what you want: keep track of all your Avaya MAC addresses. Have them SCEP to get a cert. Make SM enforce phones providing identity certs.
It sounds like you don't care if a tech shows up with a new Avaya phone for a swap or an add order. You care if I'm pretending to be an Avaya phone.
Cisco says:
Code:
Renewal
As the expiration date of an ID certificate approaches, a SCEP client might want to obtain a new certificate. The client generates a CSR and goes through the Enrollment process (as defined previously). [highlight #FCE94F]The current certificate is used in order to sign the SignedData PKCS#7, which in turn proves identity to the CA[/highlight]. Upon reciept of the new certificate, the client immediately deletes the current certificate and replaces it with the new one, whose validity starts immediately.
Wouldn't that be good enough to know that nobody swept in and stole the identity of MAC address Avaya:12:34:56?
That, with a little IDS action and locking down VLANs and ports would make it so that your hypothetical attacker would get the same network access whether you use dot1x or not, and you'd know pretty quick with intrusion detection that "a phone is trying something funny here" and you'd get your turbo security, and you wouldn't need to bend over backwards to swap phones/turn up new ones/etc.
)
I'm sure you just have a project to implement this NAC thing. But if we really wanted to put on a tinfoil hat, you could set up SNMP on the Avaya phones and have that as a validation layer to ensure they're always responding as Avaya phones should. Providing their serial numbers and interface uptimes and extensions they might be logged in with. 
