Nexpert SIP - Security - Revision history

Pchero: /* Network Asserted Identity/Privacy (Trusted) */

2019-12-12T14:31:22Z

Network Asserted Identity/Privacy (Trusted)

← Older revision		Revision as of 14:31, 12 December 2019
Line 150:		Line 150:
	지금까지 NAI(Network Asserted Identity)의 매커니즘을 살펴보았으며, RFC 3325 Private Extensions to the SIP for Asserted Identity within Trusted Netowrks 에 자세히 나와있다. RFC 3325 의 내용을 간략히 정리하면 다음과 같다.		지금까지 NAI(Network Asserted Identity)의 매커니즘을 살펴보았으며, RFC 3325 Private Extensions to the SIP for Asserted Identity within Trusted Netowrks 에 자세히 나와있다. RFC 3325 의 내용을 간략히 정리하면 다음과 같다.
	* NAI는 신뢰할 수 있는 SIP 서버 네트워크가 인증된 사용자들을 식별해주며, 그들간에 프라이버시를 형성할 수 있도록 해준다.		* NAI는 신뢰할 수 있는 SIP 서버 네트워크가 인증된 사용자들을 식별해주며, 그들간에 프라이버시를 형성할 수 있도록 해준다.
	* SIP Server가 P-Asserted		* SIP Server가 P-Asserted 헤더를 가진 신뢰할 수 있는 Entity 로부터 SIP 메시지를 받는다면, 새로운 Digest 인증과정을 거치는 대신에 인증목적으로 이 필드를 사용할 수도 있다.
			* SIP Server 가 신뢰할 수 없는 곳으로 이 메시지를 전송할 때 PAI 헤더를 제거한다면, Privacy 헤더 값은 "id"로 설정된다.
			* UAS 가 PAI 헤더를 포함한 메시지를 받는다면, From 헤더보다 더 신뢰한다. 그래서 일반적으로 From 헤더를 <anonymous>로 설정한다.

	== See also ==		== See also ==

Pchero: /* Network Asserted Identity/Privacy (Trusted) */

2019-12-12T14:00:54Z

Network Asserted Identity/Privacy (Trusted)

← Older revision		Revision as of 14:00, 12 December 2019
Line 127:		Line 127:
	Privacy 헤더는 "none"으로 표시되어 P-Asserted-Identity 가 있던 없던 상관하지 않겠다는 의미이다.		Privacy 헤더는 "none"으로 표시되어 P-Asserted-Identity 가 있던 없던 상관하지 않겠다는 의미이다.

	여기서 From 헤더가 anonymous 로 ~~ㅠㅛ시된~~ 것은 P-Preferred-Identity 가 우선적으로 사용되기 때문이다.		여기서 From 헤더가 anonymous 로 표시된 것은 P-Preferred-Identity 가 우선적으로 사용되기 때문이다.

	* P-Asserted-Identity(PAI)		* P-Asserted-Identity(PAI)

Pchero: /* Network Asserted Identity/Privacy (Trusted) */

2019-12-12T13:59:20Z

Network Asserted Identity/Privacy (Trusted)

← Older revision		Revision as of 13:59, 12 December 2019
Line 147:		Line 147:

	Digest 인증을 통해 SIP Proxy 서버는 Alice 를 인증하였으며, Audrey 는 같은 도메인내에 존재하는 신뢰할 수 있는 사용자이므로 P-Asserted-Identity 를 출가하여 INVITE Message 를 전송한다.		Digest 인증을 통해 SIP Proxy 서버는 Alice 를 인증하였으며, Audrey 는 같은 도메인내에 존재하는 신뢰할 수 있는 사용자이므로 P-Asserted-Identity 를 출가하여 INVITE Message 를 전송한다.

			지금까지 NAI(Network Asserted Identity)의 매커니즘을 살펴보았으며, RFC 3325 Private Extensions to the SIP for Asserted Identity within Trusted Netowrks 에 자세히 나와있다. RFC 3325 의 내용을 간략히 정리하면 다음과 같다.
			* NAI는 신뢰할 수 있는 SIP 서버 네트워크가 인증된 사용자들을 식별해주며, 그들간에 프라이버시를 형성할 수 있도록 해준다.
			* SIP Server가 P-Asserted

	== See also ==		== See also ==

Pchero: /* Network Asserted Identity/Privacy (Trusted) */

2019-12-12T13:56:33Z

Network Asserted Identity/Privacy (Trusted)

@@ Line 137: / Line 137: @@
 * Privacy
 : Privacy에 "id"가 있으면, 신뢰할 수 없는 곳으로 SIP Message를 전달할 때, P-Asserted-Identity Header를 삭제하고 전달해야 하며, "none"으로 표시되어 있으면 삭제하지 않고 전달한다. 만일, Privacy 헤더가 없다면, P-Asserted-Identity 헤더의 추가 또는 삭제를 마음대로 할 수 있다.
 == See also ==

Pchero: /* Network Asserted Identity/Privacy (Trusted) */

2019-12-12T13:11:33Z

Network Asserted Identity/Privacy (Trusted)

@@ Line 123: / Line 123: @@
 [[File:Sip security 4.png]]
-위의 그림에서 Alice 가
+위의 그림은 Alice 가 Audrey 에게 INVITE 를 전송하는 과정이다. 즉, UAC 가 보내는 INVITE 메시지이다. 내용을 간단히 살펴보면, From 헤더는 anonymous 로 표시되고, P-Preferred-Identity 헤더에 사용자 정보가 포함된다.
 == See also ==

Pchero at 12:59, 12 December 2019

2019-12-12T12:59:20Z

← Older revision		Revision as of 12:59, 12 December 2019
Line 96:		Line 96:
	[[File:Sip security 1.png]]		[[File:Sip security 1.png]]

	=== SIPS(TLS): Hop-by-Hop Security ===		== SIPS(TLS): Hop-by-Hop Security ==
	SIP Proxy 서버가 SIP Message를 추가 변경 삭제가 가능할 뿐만 아니라 항상 메시지 내용을 확인해야 하기 때문에 Alice 와 Bob 간의 End-to-End 로 암호화를 하는 것이 어렵다. 그래서, Hop-by-Hop 으로 처리될 수 밖에 없다.		SIP Proxy 서버가 SIP Message를 추가 변경 삭제가 가능할 뿐만 아니라 항상 메시지 내용을 확인해야 하기 때문에 Alice 와 Bob 간의 End-to-End 로 암호화를 하는 것이 어렵다. 그래서, Hop-by-Hop 으로 처리될 수 밖에 없다.

Line 111:		Line 111:
	* TLS 는 AES@128 bit 를 사용해야 한다.		* TLS 는 AES@128 bit 를 사용해야 한다.

	=== S/MIME ===		== S/MIME ==
	S/MIME는 SDP를 암호화하거나 SIP 전체 미시지에 대한 서명, 무결성을 제공할 수 있다. 아래 그림은 Alice 가 Bob 에게 INVITE 를 보내는 과정을 나타낸 것이며, SDP 부분이 암호화 되어 있다.		S/MIME는 SDP를 암호화하거나 SIP 전체 미시지에 대한 서명, 무결성을 제공할 수 있다. 아래 그림은 Alice 가 Bob 에게 INVITE 를 보내는 과정을 나타낸 것이며, SDP 부분이 암호화 되어 있다.

Pchero: /* Network Asserted Identity/Privacy (Trusted) */

2019-12-12T12:58:59Z

Network Asserted Identity/Privacy (Trusted)

← Older revision		Revision as of 12:58, 12 December 2019
Line 118:		Line 118:
	위 SIP 메시지 중에 Content-Type 헤더의 application/pkcs7-mime 이라는 파라미터는 S/MIME 임을 가리킨다. S/MIME는 SHA1 인증과 3 DES 암호화 알고리즘을 사용한다. S/MIME 는 SDP 가 암호화되어 End-to-End 간 즉, Alice 와 Bob 만이 이해할 수 있다. 따라서, 중간에서 SDP 메시지를 이해해야 하는 서비스 즉, Redirect 또는 Forking 과 같은 서비스를 같이 사용할 수 없는 것이 단점이다.		위 SIP 메시지 중에 Content-Type 헤더의 application/pkcs7-mime 이라는 파라미터는 S/MIME 임을 가리킨다. S/MIME는 SHA1 인증과 3 DES 암호화 알고리즘을 사용한다. S/MIME 는 SDP 가 암호화되어 End-to-End 간 즉, Alice 와 Bob 만이 이해할 수 있다. 따라서, 중간에서 SDP 메시지를 이해해야 하는 서비스 즉, Redirect 또는 Forking 과 같은 서비스를 같이 사용할 수 없는 것이 단점이다.

	=== Network Asserted Identity/Privacy (Trusted) ===		== Network Asserted Identity/Privacy (Trusted) ==
	도메인 내에서 Digest 가 사용자를 인증한다면, NAI 는 사용자 식별을 위해 사용되는 매커니즘이다. 둘다 비슷하지만 구체적으로는 약간의 차이가 있다.		도메인 내에서 Digest 가 사용자를 인증한다면, NAI 는 사용자 식별을 위해 사용되는 매커니즘이다. 둘다 비슷하지만 구체적으로는 약간의 차이가 있다.

	[[File:Sip security 4.png]]		[[File:Sip security 4.png]]

			위의 그림에서 Alice 가

	== See also ==		== See also ==

Pchero: /* S/MIME */

2019-12-12T12:55:31Z

S/MIME

← Older revision		Revision as of 12:55, 12 December 2019
Line 115:		Line 115:

	[[File:Sip security 3.png]]		[[File:Sip security 3.png]]

			위 SIP 메시지 중에 Content-Type 헤더의 application/pkcs7-mime 이라는 파라미터는 S/MIME 임을 가리킨다. S/MIME는 SHA1 인증과 3 DES 암호화 알고리즘을 사용한다. S/MIME 는 SDP 가 암호화되어 End-to-End 간 즉, Alice 와 Bob 만이 이해할 수 있다. 따라서, 중간에서 SDP 메시지를 이해해야 하는 서비스 즉, Redirect 또는 Forking 과 같은 서비스를 같이 사용할 수 없는 것이 단점이다.

			=== Network Asserted Identity/Privacy (Trusted) ===
			도메인 내에서 Digest 가 사용자를 인증한다면, NAI 는 사용자 식별을 위해 사용되는 매커니즘이다. 둘다 비슷하지만 구체적으로는 약간의 차이가 있다.

			[[File:Sip security 4.png]]

	== See also ==		== See also ==

Pchero: /* S/MIME */

2019-12-12T12:50:15Z

S/MIME

← Older revision		Revision as of 12:50, 12 December 2019
Line 112:		Line 112:

	=== S/MIME ===		=== S/MIME ===
			S/MIME는 SDP를 암호화하거나 SIP 전체 미시지에 대한 서명, 무결성을 제공할 수 있다. 아래 그림은 Alice 가 Bob 에게 INVITE 를 보내는 과정을 나타낸 것이며, SDP 부분이 암호화 되어 있다.

			[[File:Sip security 3.png]]

	== See also ==		== See also ==

Pchero: /* SIPS(TLS): Hop-by-Hop Security */

2019-12-12T12:49:07Z

SIPS(TLS): Hop-by-Hop Security

← Older revision		Revision as of 12:49, 12 December 2019
Line 97:		Line 97:

	=== SIPS(TLS): Hop-by-Hop Security ===		=== SIPS(TLS): Hop-by-Hop Security ===
			SIP Proxy 서버가 SIP Message를 추가 변경 삭제가 가능할 뿐만 아니라 항상 메시지 내용을 확인해야 하기 때문에 Alice 와 Bob 간의 End-to-End 로 암호화를 하는 것이 어렵다. 그래서, Hop-by-Hop 으로 처리될 수 밖에 없다.

			아래 그림에서처럼 Alice 의 전화기와 Proxy 1 간에 TLS 를 이용하여 암호화를 수행하고, 복호화한 후에 다시 암호화하여 Proxy 2 로 전송하는 과정을 반복해야 한다.

			[[File:Sip security 2.png]]

			TLS 는 Transport Layer Security 의 약자이며, 두 통신 시스템간의 데이터 무결성과 기밀성을 제공한다. TLS를 활용한 SIPS 는 다음과 같은 몇 가지 특징이 있다.
			* TLS 를 TCP 와 같은 신뢰할 수 있는 전송 프로토콜 위에서 동작한다.
			* 데이터 암호화를 위해 DES 와 같은 Symmetric 암호화를 사용한다.
			* 암호화 키는 connection 마다 유일하다.
			* MD5나 SHA 해쉬로 메시지 무결성을 나타낸다.
			* 서버와 클라이언트간에 상호 인증을 수행한다.
			* TLS 는 AES@128 bit 를 사용해야 한다.

			=== S/MIME ===

	== See also ==		== See also ==