Subject: RE: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions

From: <[email-masked]>
Date: Thu, 2 May 2002 10:31:54 +0300

Hi Johan,

> Requested change:
> 
>    The Diameter protocol's Session-Id AVP, which is globally unique (see
>    section 8.8), is used during the authorization phase to identify a
>    particular session. Services that do not require any authorization
>    still use the Session-Id AVP to identify sessions.
> 
> to
> 
> The Diameter protocol's Session-Id AVP, which is globally unique (see
> section 8.8), is used during the authorization phase to identify a
> particular session. Services that do not require any authorization
> still use the Session-Id AVP to identify sessions. Accounting messages 
> MUST use a different Session-Id from that sent in 
> authorization messages.

Somehow, the "MUST use" part of the last sentence worries me.  I think
that it may be more application specific.  I'd prefer to state something
more like:

  Accounting messages MAY use a different Session-Id from that sent in 
  authorization messages.  Specific applications MAY require different
  a Session-ID for accounting messages.

Then, the application (for example MIP) could use a MUST.

Comments?
John

---

From: Johan Johansson <[email-masked]>
Date: Thu, 02 May 2002 10:35:43 +0000

>Then, the application (for example MIP) could use a MUST.
I can understand your concern. NASREQ is in many ways very different 
from the MIP application. I think that the crucial requirement is that 
each application either states that they must be the same or that they 
must be different.

Nevertheless I think it could make things easier if things were solved 
consistently across applications. I am not religious about the choice of 
solution here. I think that the second best solution is to state that 
the same session id must be used. That said, using different session ids 
for accounting and authorization services is a more flexible solution 
and so far I am not aware of any problems with it.

MIP people, speak your mind please.

j

---

From: Tony Johansson <[email-masked]>
Date: Thu, 02 May 2002 09:12:59 -0700

Hi John and Johan,

>   a Session-ID for accounting messages.

I agree on a MAY in the Base, which would make the mip-10 work perfectly fine
as is, thus no MAY needs to be added in mip10. A MUST would be to strong and
reduce the possibilities in mip-10 to actually make use of the initial
session-Id received in the HAR as the acct-multi-seesion-id through out the
users authorized registration time.

Regards,

/Tony

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 2 May 2002 09:32:19 -0700 (PDT)

Question: shouldn't Session-ID AVP be both globally *and* temporally
unique? Globally so that it is unique to a NAS, and temporally so that it
doesn't repeat (and can be used for liveness to prevent things like CMS
cut and past attacks). 

BA

---

From: Tony Johansson <[email-masked]>
Date: Thu, 02 May 2002 15:30:52 -0700

I thought that the Session-Id AVP MUST *always* be globally unique, as stated
in Base section 8.8 :

  "The Session-Id MUST be globally and eternally unique, as it is meant
   to uniquely identify a user session without reference to any other
   information, and may be needed to correlate historical authentication
   information with accounting information. The Session-Id includes a
   mandatory portion and an implementation-defined portion; a
   recommended format for the implementation-defined portion is outlined
   below."

But I'm not really sure that I've understood your point :)

/Tony

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 2 May 2002 15:05:07 -0700 (PDT)

I guess "eternally unique" means that it never repeats, which is the same
as "temporally unique", so that this is covered. One question though is
whether the session-ID can obviate the need for a Nonce AVP with respect
to replay prevention.

---

From: Glen Zorn <[email-masked]>
Date: Fri, 03 May 2002 03:22:34 -0700

At 03:30 PM 5/2/2002 -0700, Tony Johansson wrote:
>   "The Session-Id MUST be globally and eternally unique,

Yes, I think that "eternally" pretty much covers temporality ;-)

>as it is meant

---

From: Johan Johansson <[email-masked]>
Date: Fri, 03 May 2002 16:55:21 +0200

>users authorized registration time.

I'm not sure I understand why it would stop the use of the id in the HAR 
as the acct-multi-session-id. I was only talking about the contents of 
the Session-Id AVP.

In any case, after suitable consultations and deliberations I think you 
and John are right. A MAY would be sufficient but forces the server to 
handle both cases. That works for me. Well spotted.

j