理解SIP的認證
1. 認證和加密
認證（Authorization）的作用在於表明自己是誰，即向別人證明自己是誰。而相關的概念是MD5，用於認證安全。注意MD5僅僅是個hash函數而已，並不是用於加密。因爲hash函數處理後的數據沒法進行反向恢復，這樣子的話別人沒法盜取你認證身份的口令。
加密（Encryption）的作用在於對想傳輸的數據進行處理，在網絡中即使被竊取也難以破解。加密的信息可以被破解，這需要一把鑰匙——“密鑰”。通過密鑰，我們可以對數據進行加密和解密。最有名的專用密鑰加密系統就是數據加密標準(DES), 這個標準現在由美國國家安全局和國家標準與技術局來管理。另一個系統是國際數據加密算法(IDEA),
它比DES的加密性好, 而且需要的計算機功能也不怎麼強。
2. SIP認證方式
SIP的認證是繼承了HTTP的認證方式。根據RFC2617，HTTP的認證方案主要有Basic Authentication Scheme和Digest Access Authentication Scheme兩種。而Basic方法使用的口令原文驗證的方式，易被盜取，所以SIP已經摒棄這種方式。
Digest認證方案可以對口令進行MD5包裝。一般來說，獲取口令有兩種方式：1.字典攻擊，即使用輪詢進行口令猜測的方法，如果口令簡單比較危險；另一個方法是攻擊服務器來獲得口令，如果服務器把密碼存儲起來那樣的話就可能被盜取。所以方法是服務器端不再存儲密碼原文，而是使用MD5包裝起來，這樣的話當經過MD5包裝的認證信息過來後，比較存儲的MD5數據則可知道用戶的身份了。
3. SIP認證過程
UA之間的認證
圖1-1 UA之間的認證流程
UA和Proxy之間的認證
圖1-2 UA和Proxy之間的認證流程
從以上兩圖看出，首先當UAC給UAS/Proxy發請求時；如果UAS/Proxy需要認證信息，則回覆401/407；這時UAC通過回覆信息來計算認證消息，然後重新發送 請求；如果認證不通過的話則會繼續收到401/407或403，這時UAC必須不能再次使用剛纔被拒絕的信任書進行嘗試，需要重新生成請求直至UA/Proxy認證通過。注意也可以第一次請求時就已經帶有認證信息。
當UAC在接收到401（Unauthorized）或者407（ProxyAuthenticationRequired）應答之後，重新用它的信任書來提交請求，它必須增加Cseq頭域的值，就像發送一個正常的新請求一樣。
如果認證通過的話，UA應當把這個給特定To頭域和”realm”字段的信任書cache起來，以備給這個地址下一個請求時候使用。
我們建議使用下列步驟來cache一個proxy的信任書：如果UA在給特定Call-ID的請求的401/407應答中，接收到一個Proxy-Authenticate頭域，它應當合併對這個realm的信任書，並且爲以後具有相同Call-ID的請求發送這個信任書。這些信任書必須在對話中被cache住；不過如果UA配置的是它自己的本地外發proxy，那麼如果出現要求認證的情況，那麼UA應當cache住跨對話的信任書。注意，這個意味着在一個對話中的請求可以包含在Route頭域中所經過proxy都不需要的信任書。
當服務器可以正確處理絕大部分SIP請求，有本文檔約定了兩類請求要求特別的認證處理：ACK和CANCEL。在某一個認證方案下，並且這個認證方案是使用應答來放置計算nonces（比如Digest），那麼對於某些沒有應答的情況，就會出現問題，比如ACK。所以，基於這個原因，一個服務器接受在INVITE請求中的信任書，也必須同樣接收對應ACK的信任書。UAC通過賦值所有的INVITE請求中的Authorization和Proxy-Authorization頭域值來創建一個相關的ACK消息。服務器必須接收這個ACK請求。
雖然CANCEL方法具有應答（2xx），服務器必須不能拒絕CANCEL請求，因爲這些請求不能被重新提交。通常，如果CANCEL請求和被CANCEL的請求來自同一個節點（假設某種通訊協議，或者網絡層有安全關係26.2.1節描述），服務器應當接收CANCEL請求。
可見SIP爲認證系統提供了一個無狀態的，試錯機制，這個認證機制式基於HTTP的認證機制的。通過請求和回覆來驗證用戶身份。
4. 認證消息解析
注：只講述重要字段，細節查看RFC2617。
具體爲401中的WWW-Authenticate應答頭域，相對應的爲請求的Authorization頭域；407中的Proxy-Authenticate頭域，相對應的是請求的Proxy-Authorization頭域。
a) WWW-Authenticate/Proxy-Authenticate頭域
這個頭域值包含了至少一個表明認證方式和適用realm的參數的拒絕原因。
如：
WWW-Authenticate: Digest
realm="biloxi.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
i. Realm
realm字串單獨定義被保護的區域。Realm字串必須是全局唯一的。我們強調這個realm字串必須包含一個主機名或者域名。Realm字串應當是一個可讀的能夠展示給用戶的字串。
通常，SIP認證對於特定realm（一個保護區域）是有意義的。因此，對於Digest認證來說，每一個類似的保護區域都有自己的用戶名和密碼集合。
ii. Nonce
服務器端指定的數據字符，它應在每個401迴應產生時，被唯一地創建。建議該字符以base64方式或16進制方式出現。另外，該字符在標題行中傳遞時是在引號內的，因此允許使用雙引號字符。
iii. Stale
一個標誌，用來指示客戶端先前的請求因其nonce值過期而被拒絕。如果stale是TRUE（大小寫敏感），客戶端可能希望用新的加密迴應重新進行請求，而不用麻煩用戶提供新的用戶名和口令。服務器端只有在收到的請求nonce值不合法，而該nonce對應的摘要（digest）是合法的情況下（即客戶端知道正確的用戶名/口令），才能將stale置成TRUE值。如果stale是FALSE或其它非TRUE值，或者其stale域不存在，說明用戶名、口令非法，要求輸入新的值。
iv. Algorithm
Algorithm是個字符串，用來指示用來產生摘要及校驗和的算法對。如果該域沒指定，則認爲是“MD5“算法。如果該域指定的算法無法理解，該質詢（challenge）將被忽略。
v. qop
“auth”表示鑑別方式；“auth-int”表示鑑別保護的完整性。
vi. opaque
由服務器指定的字符串，客戶端不能改動它，如果併發請求的URI也指向同一個受保護區間，則該信息將被加在這些請求的授權標題域中返給服務器。建議採用base64或16進制的字符串。
b) Authorization/Proxy-Authorization頭域
該頭域包含了具有這個UA到請求的資源所在的realm（區域）的信任書和所需要的認證支持的參數和重現保護的參數。
例子：
Authorization: Digest username="bob",
realm="biloxi.com",