An AirPlay sender can authenticate the receiver in the following order of precedence:
- MFi1 authentication if
- FairPlay authentication if
- RSA authentication if
Authentication_1bit 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 attempt2 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.
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.
More in the Encryption section.
ShairPort released, James Laird - http://web.archive.org/web/20110427032647/http://mafipulation.org/blagoblig/2011/04/08 ↩︎