On Fri, Jun 06, 2008 at 04:49:59PM +0200, Dragos Vingarzan wrote: > I also find this quite annoying. The 3GPP standards indicate that the UE > "shall" add that initial header, so if you are in the 3GPP IMS scope, it > works. > > After implementing AKA and using it for quite some time, I would say > that the presence of an Authorization header in the first request > indicates that the client knows how to do AKA. If you don't see one, > don't bother sending an AKA challenge. But this is just an experience > fact, so to say, and not a written fact. > > And I would add that I don't think that there is another way of > auto-detecting the username either. The best example is when I have 2 > phones with 2 ISIMs, but they share the same AOR. The requests would be > identical for both, yet the challenge must be generated accordingly for > each of them.
cristian: hi! dragos, I am refering strictly to the rfc3310 and I am trying to understand how the call flows given as an example there would function in the most general case, that is: 1. the AKA key is shared btw. an AuC and a certain authorization username 2. the sip proxy does not have yet the authentication vector and needs to get it somehow from the AuC. 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. but then again my interpretation of the rfc3310/call flows given as an example there may be wrong. that is why I am asking for an oppinion on this mailing list. thanks. bye now! cristian _______________________________________________ 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
