search

onvif / specs

ONVIF Network Interface Specifications
Other
325 stars 87 forks source link

Please add recommendations how to implement support for key exchange with MIKEY #436

Closed sirzooro closed 5 days ago

sirzooro commented 1 month ago

Learning how to implement and use MIKEY protocol is painful. RFC 3830 does not have any examples and recommendations, so connecting all dots to understand whole picture is hard. One also cannot simply verify that his/her code generates the same binary messages and is able to decode them properly. Other MIKEY-related RFC are also not very helpful in this manner. Other MIKEY-related materials on the web also usually do not have examples or they are invalid. Fortunately I was able to found few posts from people who has problems with their SIP software and posted some SDPs with MIKEY messages. I also found that GStreamer and Live555 have open source implementations of MIKEY, so I had something to learn from.

Some points however are still unclear for me. The same was for GStreamer and Live555 authors, as their implementations are not fully interoperable:

  1. RFC 3830 defines three MIKEY modes: MIKEY-PSK, MIKEY-PK and MIKEY-DH. PSK and PK are mandatory to implement. However GStreamer and Live555 implements MIKEY-NULL only (i.e. MIKEY-PSK with no authentication and encryption). GStreamer at least relies on TLS encryption to provide confidentiality. Live555 does not, at least its RTSP client does not recognize rtsps URI scheme so players like VLC does not support it too (shame on you Live555!);
  2. RFC 3830 asks to put placeholders with SSRC=0 in header for incoming RTCP. Some implementations do this, some not;
  3. Key type sent in Key payload differs. GStreamer and Live555 set it to TEK and send concatenated key+salt (I think this is incorrect and TEK+SALT should be used instead). GStreamer in recent versions also supports TEK+SALT format for received messages, so some RTSP servers must use it;
  4. Key Validity also differs. GStreamer supports Null only, i.e. SRTP without MKI. Live555 supports 4-byte MKI only;
  5. RFC 4567 asks to also add General Extension Payload with SDP IDs type, but GStreamer and Live555 does not do this. I saw it in some SIP SDP only;
  6. RFC 3830 uses SHA-1 in few places. It is not used for anything in MIKEY-NULL. If you would like to replace it with SHA-256 anyway, necessary extensions are defined in RFC 6043.

Please add recommendations how to use MIKEY to ONVIF specification, with some example message(s).

sirzooro commented 1 week ago

Additional thing to consider is how to perform re-keying in RTSP protocol. RFC 4567 does not say how to do this. Things are complicated by fact that server is an initiator of key exchange and sends initiator MIKEY message in response to DESCRIBE. I saw some non-standard solution which used SET_PARAMETER for this.

RTSP 2.0 also does not specify this explicitly, but standard-compliant way can be guessed from specification. Here client is initiator of key exchange and it sends initiator MIKEY message in SETUP request. SETUP message may also be used to change transport parameters on the fly. This means that it could be used to perform re-keying as specified in MIKEY RFC.

HansBusch commented 5 days ago

There is currently work ongoing on extending this part of the specification. With that examples may be added.