Eugene Christensen
2014-07-08 14:46:53 UTC
Hello,
I am curious about how the industry at large is securing the exchange of AES keys in SDP, or is it.
RFC4568 points out in Section 1 that "AKE is needed because it is pointless to provide a key over a medium where an attacker can snoop the key, alter the definition of the key to render it useless, or change the parameters of the security session to gain unauthorized access to session-related information". It suggests using "MIKEY, GDOI, KINK, IKE, Secure Multiparts, or TLS" to securely disseminate such information.
Later in section 8.3, it states "When the communication path of the SDP message is routed through intermediate systems that inspect parts of the SDP message, security protocols such as [IPsec] or TLS SHOULD NOT be used for encrypting and/or authenticating the security description".
Since my desire would be to develop AES in our device such that it will properly interface with other devices, proxies, etc., I would like to better understand what is being done in the industry? Are companies using s/mime, TLS, SIPS, DTLS-SRTP, all-of-the-above? Is there a prevalent trend towards one or the other?
Also, besides the RFCs (4568, 3711, 3853, 4567, 5751, 5764), is there a good primer out there for better understanding the whole AES topic that is explained in easier terms for someone that has not dealt with encryption before?
Thanks in advance for your time and advice.
Eugene R. Christensen
Principal Software Engineer
Sorenson Communications
4192 South Riverboat Road
Salt Lake City, Utah 84123
P. 801.287.9419
CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail at echristensen at sorenson.com<mailto:gbeckmann at sorenson.com> or by telephone at 801-287-9419, and destroy the original transmission and its attachments without reading them or saving them to disk.
I am curious about how the industry at large is securing the exchange of AES keys in SDP, or is it.
RFC4568 points out in Section 1 that "AKE is needed because it is pointless to provide a key over a medium where an attacker can snoop the key, alter the definition of the key to render it useless, or change the parameters of the security session to gain unauthorized access to session-related information". It suggests using "MIKEY, GDOI, KINK, IKE, Secure Multiparts, or TLS" to securely disseminate such information.
Later in section 8.3, it states "When the communication path of the SDP message is routed through intermediate systems that inspect parts of the SDP message, security protocols such as [IPsec] or TLS SHOULD NOT be used for encrypting and/or authenticating the security description".
Since my desire would be to develop AES in our device such that it will properly interface with other devices, proxies, etc., I would like to better understand what is being done in the industry? Are companies using s/mime, TLS, SIPS, DTLS-SRTP, all-of-the-above? Is there a prevalent trend towards one or the other?
Also, besides the RFCs (4568, 3711, 3853, 4567, 5751, 5764), is there a good primer out there for better understanding the whole AES topic that is explained in easier terms for someone that has not dealt with encryption before?
Thanks in advance for your time and advice.
Eugene R. Christensen
Principal Software Engineer
Sorenson Communications
4192 South Riverboat Road
Salt Lake City, Utah 84123
P. 801.287.9419
CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail at echristensen at sorenson.com<mailto:gbeckmann at sorenson.com> or by telephone at 801-287-9419, and destroy the original transmission and its attachments without reading them or saving them to disk.