加载中…
个人资料
伊顿文具
伊顿文具
  • 博客等级:
  • 博客积分:0
  • 博客访问:12,931
  • 关注人气:7
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
谁看过这篇博文
加载中…
正文 字体大小:

建立基本的VoIP服务-认证

(2011-08-10 17:08:58)
标签:

voip

杂谈

分类: VOIP

1      认证

为了对使用服务的用户进行收费,有必要进行注册和呼叫信令认证。本节给出H.323SIP进行认证所使用的各种机制。

1.1       H323的认证

H.323协议框架使用H.235安全与加密作为H-系列(H.323以及其它基于H.245) 多媒体终端的可选功能。H.235描述了如何在H.323通信中结合认证、完整性和保密,以及所支持的安全基础设施和技术。

1.1.1 应用领域

H.235可以被应用于H.323通信的各个方面,可以分成两类:信令消息的安全和媒体流的安全。

信令消息的安全用于端点注册、呼叫的管理和状态的RAS通道(2.2.1.3),用于呼叫建立的信令通道(H.225)以及媒体控制通道(H.245)

媒体流的安全为所传输的语音和视频数据提供保密。

1.1.2 用户认证

用户认证过程是用户完成一系列动作来证明其相对于服务器的身份。一般说来,有三种不同的认证方法:使用对称加密的口令,使用散列的口令,以及公钥加密机制。

1. 对称加密的口令: 这种方法基于这样的想法,通信中的双方共享一个密钥,即一个口令,及每个端点都有唯一的事先通过某种外部方式配置的generalID,这个generalID双方都知道。

希望被认证的端点生成一个加密令牌(CryptoToken),其中包括发送者的generalID,接受者的generalID,时间戳记和一个随机数(单向增加,使得具有相同时间戳记的消息唯一),使用共享密钥来加密(从共享口令中推导出来)。

加密可以采用DES3DES或者其他在ISO/IEC 9979中注册的密算法来实现。厂商也有可能使用自己的加密算法,尽管这样会有互操作的问题。

2. 散列口令: 这种方法与上一种类似,其中的CryptoHashedToken使用generalID和时间戳记来进行散列计算,如HMACMD5,或者其他在ISO/IEC 9797种定义的算法。.

3. 公钥加密: 这种方法也生成加密令牌(CryptoToken),但是使用了非对称加密算法。因此可以使用签名卡和证书。

1.1.3 完整性

完整性指的是消息完整性,确认所接收到的和发送者发送的消息完全一致,没有被篡改。

H.235支持两种机制来实现完整性:采用加密令牌(CryptoToken)和完整性检查值(IntegrityCheckValue)

1. 加密令牌已经在4.3.1.2节中叙述过。为了进行完整性检查,整个消息都用来计算MAC/数字签名,而不是像认证那样只使用一个子集。

这种机制可以用于任何一种信令通道(RAS/H.225.0/H.245)

2. 完整性检查值指的是出现在RAS消息中的元素。传输的是消息(未作散列)的散列值。

第二种机制是在采纳H.235之前引入的,因为它天生就很关键,对于不可靠的RAS通道,还没有一个数据完整性的机制。自从采纳了H.235,加密令牌方法变成了检查完整性的优选。

1.1.4 保密性

保密性的范畴从安全的H.225.0信令通道到安全的媒体流。H.323/H.235协议包没有指定保证信令通道安全的方法,因为在每个呼叫中信令通道是最先被使用的,必须从一开始就要保证安全。可以使用TLSIPSEC来保证H.225.0通道的安全。支持这种机制的端点必须侦听已知端口(如用于TLS1300)来接受安全连接。

H.225.0中,H.245媒体控制通道的安全能力可以被交换。H.245通道本身可以被用于协商媒体加密。

1.1.5 安全概要

H.235定义了三个安全profiles, - ‘Baseline security profile’‘Signature security profile’ ‘Voice encryption security profile’。每个profile定义了H.235机制的集合,端点必须支持这些机制。

Baseline security profile是最简单的profile,适合在基于口令的环境中提供认证和完整性检查。多数声称支持H.235的端点实现了这个profile

Signature security profileBaseline security profile类似,只是使用了数字签名而不是口令。

Voice encryption security profile定义了实现媒体流加密的机制。它可以与其他的事先认证的安全profile一同使用。

1.1.6 H.235与现实世界

H.235已经存在有数年的时间,但是没有很多的H.323产品支持它。某些产品只在关守和网关之间的通信中使用H.235(基本的安全功能),而不用于和端点之间的通信。甚至于在端点使用H.235通信的情况下,不同厂商之间的产品还不能够互操作。这是因为H.235没有强制要求使用一个最小的算法集合,或者生成token所必需包含的元素。因此当在IP网络内实现H.235时,要征询IP电话厂商有关兼容设备的列表。

1.2      SIP的认证

本节描述SIP所使用的认证机制。首先介绍digest认证,接下来简要介绍如何把digest认证应用于SIP消息,什么时候应该使用,什么时候不应该使用。

1.2.1 Digest认证简介

Digest认证最早是为HTTP开发的一种简单认证机制,因此也叫作HTTP digest(参看RFC2671)。这个认证机制非常简单,基于cryptographic hash来防止用户密码的明文传输。

Digest认证验证知道共享密钥(一个口令)的通信双方。当服务器对用户认证时,产生一个digest challenge并把它发送给用户。下面是一个典型的digest challenge

Digest realm="test.org", qop="auth,auth-int",

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="", algorithm=MD5

其中包括了一组发送给用户的参数。用户利用这些参数产生一个正确的digest回应,并把这个回应发送给服务器。digest challenge中的参数的含义如下:

- realm所有的challenge都必须有这个参数。它的目的是在SIP消息内部识别credential(证书)。在SIP中,通常设置为代理服务器所负责的域。SIP用户代理显示参数的内容给用户,提示输入用户名、口令。

- nonce:这是一个与服务器相关的数据串,每次服务器产生digest challenge时生成这个串。Nonce通常是某些数据的MD5。这些数据通常包括时间戳记和生成服务器的密码短语。这样确保每个nonce的生命期是有限的(即超过有效期后不能再用)并且是唯一的。客户端使用这个nonce产生digest回应,因此服务器会接收到在digest回应中的nonce的内容。服务器通常在检查digest回应中的其他内容之前首先检查nonce的有效性。所以,nonce是一种标识符,能够确保所接收到的digest证书是真正为特定的digest challenge生成的,同时也限制了digest回应的生命期,从而防止中继攻击。

- opaque: 这是在challenge中传送给用户的opaque数据串,用户会在digest回应中把这个串再传给服务器,这样做允许服务器是无状态的。假如有任何的状态需要在challenge和回应之间维持,可以使用这个参数来传递状态给客户端,然后再从digest回应中读出来。

- algorithm: 用来做hash的算法。目前支持MD5

- qop: 保护的质量。这个参数指定了服务器支持什么样的保护方案。客户端将从裂变中挑取一个。值‘auth’表示只做认证。值‘auth-int’认证同时加一些完整性保护。更具体的说明请参考 RFC2617

在接收到digest challenge之后,用户代理将提示用户输入用户名和口令(假设没有预先设定),然后生成digest回应,并将其发送给服务器。digest回应看起来如下所示:

Digest username="jan", realm="test.org",

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:test.org",

qop=auth, nc=00000001, cnonce="0a4f113b",

response="6629fae49393a05397450978507c4ef1", opaque=""

digest回应类似于digest challenge。相同名字的参数与digest challenge中的参数具有相同的意义。下面是一些新的参数的说明:

- uri: 这个参数包含的是客户端要访问的URI

- qop: 客户端选择的保护级别;

- nc: (nonce count) 这个值代表的是客户端用这个nonce值发送的请求的计数(包括当前请求),为16进制。例如,在第一个请求中,应给定的nonce值所发送的,客户端发送nc=00000001。这个directive的目的是让服务器通过维持其自己的计数的副本来检测请求中继。如果两次看到相同的值,那么这个请求就是中继的;

- cnonce: 该值是一个不透明的字符串,由客户端提供,并且由客户端和服务器使用,避免使用普通的明文而受到攻击,以便提供多次认证和完整性保护机制。

- response: 由用户代理计算所得到得字符串,证明用户知道口令。在收到一个digest回应之后,服务器重新计算响应参数的值来进行比较。计算采用来自客户端提供的属性和保存在服务器上的口令。如果结果与从客户端所接收到的响应一致,就说明客户端知道正确的口令,认证通过。

1.2.2 Digest认证与SIP

我们已经概要的描述过了digest challenge和回应,但是如何把它应用到SIP消息尚未介绍。由于这种认证机制原来是为HTTP协议所开发,而SIP协议与HTTP又很相似,所以digest challenge和回应映射到SIP消息很容易,并且很直接。digest认证在RFC3261中描述。

SIP服务器接收到SIP请求,在处理请求之前,要验证用户的真伪(authenticity),看这个请求是否含有digest证书。如果在请求中没有包含证书,服务器将产生一个否定的最终回应,并且将digest challenge包含在回应中。

当客户端接收到回应(包括digest challenge)后,就计算正确的digest回应并且再次发送请求,这次包括计算出来的digest证书。

服务器然后验证这个digest回应,如果成功,则对请求进行处理。

代理服务器使用Proxy Authentication Required响应并且把digest challenge包括在 Proxy-Authenticate头域内。一个这样的challenge的例子看起来如下:

SIP/2.0 407 Proxy Authentication Required.

Via: SIP/2.0/UDP 195.37.78.121:5060.

From: sip:jan@test.org;tag=3944790419.

To:<sip:5060@test.org;user=phone>;tag=794fe65c16edfdf45da4fc39a5d2867

Call-ID: 3541699089@195.37.78.121.

CSeq: 1 INVITE.

Proxy-Authenticate: Digest realm="test.org", \

nonce="3f9fc19cf91f65958f664122c1310d4c28cc61a2".

Content-Length: 0.

对于digest challenge SIP用户代理(包括注册服务器-registrarsback-to-back用户代理) 使用 401 Unauthorised回应消息。下面是一个challenge的例子:

SIP/2.0 401 Unauthorised.

Via: SIP/2.0/UDP 218.79.100.193:65030;branch=z9hG4bK1ce21dab.

To: "IPTel844978" <sip:844978@test.org>;tag=794fe65c16edfdf45da4fc39

From: "IPTel844978" <sip:844978@test.org>;tag=1fd6218e.

Call-ID: 2d471abf-c0fbee95-bee93355-fea1736b@218.79.100.193.

CSeq: 88608141 REGISTER.

WWW-Authenticate: Digest realm="test.org", \

nonce="3f9fc19cf91f65958f664122c1310d4c28cc61a2".

Content-Length: 0.

407回应消息不是由最终的请求目标的SIP元素(大多为SIP代理服务器)使用,并且在认证之后,还会继续转发请求。401回应由最终的请求目标的SIP元素使用,并且在认证之后,产生最终的回应。

当包括digest response时,客户端添加一个包括digest responseAuthorisationProxy-Authorisation头域。下面的例子说明了包含digest证书的REGISTER消息。

REGISTER sip:iptel.org SIP/2.0.

Via: SIP/2.0/UDP 195.37.78.121:5060.

From: sip:jan@test.org.

To: sip:jan@test.org.

Call-ID: 003094c3-bcfea44f-40bdf830-2a557714@195.37.78.121.

CSeq: 102 REGISTER.

User-Agent: CSCO/4.

Contact: <sip:jan@195.37.78.121:5060>.

Authorisation: Digest username="jan",realm="test.org",

uri="sip:test.org",response="dab81127b9a7169ed57aa4a6ca146184",

nonce="3f9fc0f9619dd1a712b27723398303ea436e839a",algorithm=md5.

Content-Length: 0.

Expires: 10.

1.2.3 基本的场景

前面是对digest认证和digest如何challenges,以及响应如何在SIP消息中承载的一个描述。本节介绍两个常见的使用digest认证的情形。

SIP用户接收到一个digest challenge,它会重新发送一遍这个请求,但是使用了正确的digest证书。这也意味着用户代理必须在请求中增加CSeq编号,避免服务器把这个新的请求看作重传的请求。

由于challenge一个请求意味着用更高的CSeq来重发请求,因此不能够challenge ACKCANCEL请求,因为这两个请求与原始的请求有相同的CSeq

所有其它的请求都可以被challenge,尽管不时地出现一些实现有不平常的SIP请求的challenge问题。

有两种情况部署的最多,我们在下面的两节中进一步探讨REGISTER消息的认证和INVITE消息的认证。

1.2.3.1 注册认证-REGISTER

REGISTER消息的认证非常重要,每个SIP代理服务器都应该做这个认证。利用REGISTER消息,SIP用户代理向服务器通告他们现在的位置,从而服务器知道把请求发送到哪里。

如果服务器不对REGISTER请求进行认证,那么任何人都可以用任何的联系人注册为任何用用户,从而截听那个人的通话,这显然是要受到保护的,因此REGISTER消息的认证应该被打开。图4.9显示了一个典型的包括注册的SIP注册流程。

4.9 REGISTER消息流程

1.2.3.2 Invite认证

INVITE消息的认证有时并不真正需要,但这样做是一个很好的方式。SIP代理服务器只能够challenge来自代理服务器所负责的同一个管理域的用户的请求。例如,test.org 域只能够challengeFrom头域中包含test.org的请求。来自外界用户的请求通常在这个服务器上没有用户名和口令,因此设置认证限制了来自外界用户的呼叫。图4.10challenge INVITE的呼叫流程。

 

4.10 没有认证的INVITE

0

阅读 评论 收藏 禁止转载 喜欢 打印举报/Report
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有