Subject: [Sip] aka authentication and sip (rfc 3310)

From: cco <[email-masked]>
Date: Fri, 6 Jun 2008 11:30:37 +0200

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dragos Vingarzan <[email-masked]>
Date: Fri, 06 Jun 2008 16:49:59 +0200

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

---

From: cco <[email-masked]>
Date: Sun, 8 Jun 2008 22:08:46 +0200

> identical for both, yet the challenge must be generated accordingly for 

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

---

From: Aki Niemi <[email-masked]>
Date: Tue, 10 Jun 2008 11:55:43 +0300

> 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
requiring the presence of the Authorization field in the initial
REGISTER. 

Cheers,
Aki

---

From: cco <[email-masked]>
Date: Tue, 10 Jun 2008 12:27:24 +0200

> 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?

> requiring the presence of the Authorization field in the initial

cristian: why not specifying this in the rfc as well?

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. and in the end, everyone will wonder 
why the call flow in rfc3310 does not work or when it works it looks 
quite differently...

bye now!
cristian

---

From: Aki Niemi <[email-masked]>
Date: Thu, 12 Jun 2008 12:34:28 +0300

> 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.

> 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.

> how it is specified in the rfc. 

Not necessarily a bad thing...

> and in the end, everyone will wonder 

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