ti, 2008-06-10 kello 12:27 +0200, ext cco kirjoitti: > On Tue, Jun 10, 2008 at 11:55:43AM +0300, Aki Niemi wrote: > > su, 2008-06-08 kello 22:08 +0200, ext cco kirjoitti: > > > now, the call flows given as an example would function when the > > > challenge (nonce) does not explicitly depend on the user which is > > > actually trying to register itself, being generated > > > (periodically) by the sip proxy itself; that is they are o.k. for an > > > HTTP digest MD5 auth. as spec. in rfc 3261/rfc 2617. but they do NOT seem > > > to > > > function in the real world when AKA is used, because: > > > > > > 1. the challenge is user specific. > > > 2. the "network" authenticates itself to the UE as well in case of AKA. > > > > In an environment with plain RFC3310, an extra round trip would be > > required. The main user of this spec, namely 3GPP fixes this by > > cristian: hi. aki, thanks a lot for the reply. I still have some > questions though. lets take it one step at a time. "an extra round trip > would be required" means that the call flow given as an example in the > rfc lacks that round trip, right? why?
Well, the REGISTER header is not visible, so it indeed could contain an Authorization field, as it normally would if there are cached credentials. > > requiring the presence of the Authorization field in the initial > > REGISTER. > > cristian: why not specifying this in the rfc as well? I don't think it matters. I can't see Digest AKA very useful beyond 3GPP IMS anyway, which means implementing a bunch of their TSs. > now, as I see it, the problem is that a lot of ue sip stacks implementors > would take the rfc word for word and implement their software exactly > how it is specified in the rfc. Not necessarily a bad thing... > and in the end, everyone will wonder > why the call flow in rfc3310 does not work or when it works it looks > quite differently... There isn't a big difference, really. Look at it as there always being a set of cached credentials at the UA that are included in every REGISTER. It just happens that the UA always gets a 401 in response. Cheers, Aki _______________________________________________ Sip mailing list https://www.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
