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.
I hope we get a more authoritative answer though.... Anyone?
Cheers,
-Dragos
cco wrote:
> hi!
>
> in either of the signalling flow examples given in the rfc 3310 (4. Example
> Digest AKA Operation), the first non-auth REGISTER does not contain an
> "Authorization" header. also the rfc does not seem to enforce the usage
> of an "Authorization" header right on from the first register.
>
> now, considering that:
>
> 1. an correct AKA challenge is user dependent.
> 2. in order to generate the correct AKA challenge the proxy may need
> information about both:
> a. the aor (From/To headers of the REGISTER) and
> b. the authentication username ("username" parameter of the "Authorization"
> header)
>
> the question is how should the proxy generate a correct AKA challenge when
> the "Authorization" header is not present in the first (non-auth.)
> REGISTER?
>
> 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
>
>
_______________________________________________
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
