>> federated authentication > What is it? Think Jabber, AD, kerberos, email... those are federated environments. Basically you tie a user to a domain, have s

>> federated authentication > What is it? Think Jabber, AD, kerberos, email... those are federated environments. Basically you tie a user to a domain, have some way to discover all domains, and design an authentication that can be trustworthy enough for the interaction of multiple domains. The end result is that your username is (more or less) trusted on other domains. Of course, it does not mean that what I'm building is limited to federation, but it simplifies a lot of things after a while. > There is a "message authentication hash" being sent in messages and I can't see anything about that in the spec, so that might be it? By the name it is either that or you are talking about the MAC of each packet, but it could be that, yes. > * I don't think it makes much sense to prove that you own the IP after the handshake has been done. It's mostly a countermeasure to DoS attacks for the very first handshake message > * The client should actually be able to roam and change IP without having to re-negotiate a secure connection with the server, as long as it uses the same 64-bit connectionID. Yes, I think only QUIC has such a mechanism. It was probably introduced exactly to handle roaming stations, and avoid having to require another check before the server can send data to the new IP. If no such check is in place, then you could start a file transfer and then spoof the source IP to that of someone you wanted to DoS.