Authentication

Authentication methods

An AirPlay sender can authenticate the receiver in the following order of precedence:

MFi¹ authentication if Authentication_8 or SupportsUnifiedPairSetupAndMFi are enabled;
FairPlay authentication if Authentication_4 is enabled;
RSA authentication if Authentication_1 bit in features is enabled.

When none of those bits are set, sender stops the pairing and logs an error hinting authentication is mandatory and must be enabled (or not?).

Apple seems to have disabled RSA authentication, probably to block another James Laird-like attempt² as already happened for the AirPort Express back in 2011. Enabling RSA authentication triggers a “Not supported for AirPlay sessions” error in the sender logs.

If FairPlay authentication is enabled the sender issues a POST /fp-setup RTSP/1.0 request. If MFi authentication is enabled the sender issues a POST /auth-setup RTSP/1.0 request.

If the receiver declares SupportsHKPairingAndAccessControl, then the authentication process is initiated after pairing is established.

Disabled authentication

Apple tests MFi authentication support with an OR condition. Moreover, the actual authentication phase begins only if bit Authentication_8 is set. In other words when only SupportsUnifiedPairSetupAndMFi is enabled, 1) we pass the authentication checks, 2) the sender actually doesn't start any authentication setup. This sounds like a logic bug that could be fixed in the future, unless Apple keeps it as an undocumented feature… Authentication can still be disabled as of iOS 13.3.