. In both schemes, a server challenges the client with a 400-class response that asks for the appropriate credentials. The client responds with a new request containing what the server required. Challenges are carried in the WWW-authenticate SIP header and creden- tials are carried in the Authorization header (Figure 6-19). In the basic authentication scheme, the client provides a user ID and a password as credentials. This mechanism has an important limitation: both user ID and password are sent in clear text. Thus, any eavesdropper can readily obtain them just by sniffing the network. The digest authentication scheme overcomes that limitation. It is also based on user IDs and passwords, with the difference that they are never sent through the network. The server challenges the client sending a nonce value. Then the client calculates a checksum of the nonce value, the Request-URI, the SIP method, the user, ID and the password and sends it to the server. The server can thereby confirm that the client knows the user ID and password without ever exposing them. Laura Figure 6-19 Example of HTTP (1) INVITE authentication (2) 401 Unauthorized mechanisms WWW-authenticate: (challenge) used in SIP. (3) ACK (4) INVITE Authorization: (Credentials) (5) 200 OK (6) ACK Conversation Extending SIP: The SIP Toolkit These two mechanisms provide a level of authentication, but are not enough for applications that require strong authentication. The basic and digest schemes have serious limitations. A malicious proxy in the middle of the SIP path could change the contents of the SIP message generated by Bob and forward it to Laura. When Laura checks the Authorization header of the message, she'll believe that it's from Bob. However, the proxy has changed some parameters of Bob's request so that even if Bob did generate the original message, what Laura received is not really what Bob sent. To overcome this weakness in the basic and digest authentication schemes, it is necessary to provide message integrity together with authen- ticati