This is very similar to establishing transport security with entity authentication. In other words, this would be much like TLS, except that in this case the client seems to require authentication rather than the server.
Still, using TLS with client authentication would probably solve your needs. Sure, it would also encrypt the streams, but that should not necessarily pose a problem. Otherwise you could replace the encryption and authentication with just HMAC and skip encryption.
Otherwise it would be a very good idea to study the TLS handshake and work out how the entity authentication works and how the shared session keys are established. Once the session keys are established they can be used to authenticate the records / messages in the stream. These are just blocks of data that together form the stream.
Beware that designing / implementing transport security is fraught with danger and should not be attempted without a very good understanding of the subject.
Note that SSH is usually more geared towards client authentication rather than TLS, which requires server authentication. So SSH might be a better transport security protocol when it comes to fulfilling the requirements. I'm however less at home with the current security details of SSH.
Another option would be to sign the data before sending (application level security rather than transport security). This would let you verify that the stream was delivered by a certain entity even after transport. If this is a valuable property depends on your usage scenario; it might be a very dangerous one as well - others would also be able to verify that it was delivered by the entity that signed it after all.
This seems to be the current road you're on; however in this scenario you might as well sign the whole stream / file rather than blocks. Otherwise you would just be designing a pretty bad transport mode security without forward secrecy, a lot of overhead and a proprietary messaging layer.