Michael, thank you for the background. Is there any reason mutual authentication would not be desired for UA to Proxy authentication (or is it assumed that all clients support TLS/IPsec to allow the UA to authenticate the Proxy)? The Proxy-Authentication-Info header also delivers nextnonce, which as I understand, allows the UA to provide its challenge-response pre-emptively on subsequent messages, in environments where authentication of non-REGISTERs is performed. Nonce-count is still an option, but if I want to use a fresh nonce for each authentication I have to complete another round trip.
Does anyone remember these details being discussed? Thanks. Steve. -----Original Message----- From: Michael Procter [mailto:[EMAIL PROTECTED] Sent: Friday, August 31, 2007 4:15 AM To: Fries, Steffen; [email protected] Subject: RE: [Sip] Allowed SIP Header Fileds Hi Steffen, Proxy authentication on the client side is performed using the headers 'Proxy-Authenticate' and 'Proxy-Authorization' in the same way as user to-user authentication uses the headers 'WWW-Authenticate' and 'Authorization'. The extra header 'Authentication-Info' is allowed by RFC3261 Section 22.4, last paragraph: RFC 2543 did not allow usage of the Authentication-Info header field (it effectively used RFC 2069). However, we now allow usage of this header field, since it provides integrity checks over the bodies and provides mutual authentication. Authentication is possible with just the normal 2 headers. But other benefits occur when using the third header (Authentication-Info) in the user-to-user case, sufficient to make RFC3261 permit it. Presumably the advantages were not sufficient for the comparable user-to-proxy case. Regards, Michael > -----Original Message----- > From: Fries, Steffen [mailto:[EMAIL PROTECTED] > Sent: 31 August 2007 09:54 > To: [email protected] > Subject: [Sip] Allowed SIP Header Fileds > > Hi, > > just a question regarding the allowed SIP header field in RFC 3261. > The Table 2 in section 20 states the corresponding headers for WWW- > Authenticate and Authentication-Info but it does only state Proxy- > Authenticate. While RFC2617 stated the Proxy-Authentication-Info > header, RFC3261 does not. What is the reason for the removal and how > is the Proxy Authentication on client side (via digest authentication) > to be done in this case? > > Ciao > Steffen > > > > ------------------------------------------- > > Steffen Fries > > Siemens AG, CT IC 3 > > Otto-Hahn-Ring 6, 81730 Munich, Germany > > Phone: (+49) 89 / 636-53403, > > Fax : (+49) 89 / 636-48000 > > email: [EMAIL PROTECTED] > > ------------------------------------------- > Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard > Cromme; > Vorstand: Peter Löscher, Vorsitzender; Johannes Feldmayer, Heinrich > Hiesinger, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, Jürgen > Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef, Klaus > Wucherer Sitz der Gesellschaft: Berlin und München, > Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684 > WEEE-Reg.-Nr. DE 23691322 > > ___________________________________________ > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > [EMAIL PROTECTED] for questions on current sip Use > [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
