Subject: [AAA-WG]: Pending Issue about MIP-Key-Lifetime AVP

From: "Bob Kopacz" <[email-masked]>
Date: Fri, 22 Feb 2002 08:38:30 -0500

Hi Tony,
 
> Yes I agree, could you please submit a new issue for this. 
> So, we don't forget it.
 
The above is from an email you sent me on 1-Feb, Subj: "Re: [AAA-WG]:
[issue] Returning AAAF-Generated FA-HA Key to FA", where I had asked a
few questions about the MIP-Key-Lifetime.
 
I just now rediscovered that I never did submit this issue.
 
However, before I submit an issue about MIP-Key-Lifetime AVP, I want
to get your take on a few further things regarding MIP-Key-Lifetime,
so I can submit a more complete issue.  My questions reflect my
ignorance.

The following is a numbered list.  The "-->" indicates either a
question, or what I believe is the answer.  The "-->" things are what
is to be addressed in the pending MIP-Key-Lifetime AVP issue.

(1) There is a single MIP-Key-Lifetime AVP which contains the lifetime
that applies to all the keys.  
 
--> The draft should add the following clarifications:
 
    "Since the AAAH is the owner of the MN, the AAAH specifies the key
    lifetime for the keys it generates as well for as the HA-FA key, if
    generated by the destination AAAF.  Therefore, even if the AAAH isn't
    generating any keys and the only key being generated is the HA-FA key
    by the destination AAAF, the AAAH must remember to pass the
    MIP-Key-Lifetime AVP in the HAR."

(2) Section 1.2 of the mobile-ip draft says:
 
|  "The expiration time of the
|  authorization (and session keys, if allocated by the AAA server) is
|  communicated through the Authorization-Lifetime AVP in the AA-Mobile-
|  Node-Answer from the AAAH."
 
--> The sentence should be rephrased to remove the parenthesized
phrase, or to remove the parenthesized phrase and add the sentence
"The expiration time of the session keys is communicated through the
MIP-Key-Lifetime AVP in the AA-Mobile-Node-Answer from the AAAH."

(3) The base draft says a number of things about the Auth-Lifetime
AVP, such as:
 
3a.  The relationship of the Auth-Lifetime value and the
Session-Timeout value (i.e. Auth-Lifetime value <= Session-Timeout
value)
 
3b.  The state transitions and actions that take place, for both the
server and the access device, when the Auth-Lifetime (+grace period)
expires.
 
3c.  How the client can send the Auth-Lifetime as a "hint" to the server.
 
draft-mobileip-08 doesn't say nearly so much about the
MIP-Key-Lifetime regarding 3a, 3b, and 3c above (with "Auth-Lifetime"
replaced by "MIP-Key-Lifetime" in 3a, 3b, and 3c above).
 
What draft-mobileip-08 says is the following:
 
|  6.13 MIP-Key-Lifetime AVP
|  
|  The MIP-Key-Lifetime AVP (AVP Code 367) is of type Unsigned32 and
|  represents the period of time (in seconds) for which the session key
|  is valid.  The session key MUST NOT be used if the lifetime has
|  expired; if the key lifetime expires while the session to which it
|  applies is still active, either the session key MUST be changed or
|  the or the session MUST be terminated.
 
So ...
 
(4) The draft-base-08 says the following things about the 
Authorization-Lifetime AVP, and the "-->" indicates that the same
sorts of things should be addressed for the MIP-Key-Lifetime AVP:
 
|  base-08 Section 2.0 "Protocol Overview" says:
|
|  Session state (associated with a Session-Id) MUST be freed upon
|  receipt of the Session-Termination-Request, Session-Termination-
|  Answer, expiration of authorized service time in the Session-Timeout
|  AVP, and according to rules established in a particular Diameter
|  application.
|
|
|  base-08 Section 8.1 "Authorization Session State Machine" says:
|
|     Open      Authorization-Lifetime (and    Cleanup    Discon
|               Auth-Grace-Period) expires
|               on home server.
|
|     Open      Session-Timeout expires on     Cleanup    Discon
|               home server
|
|     Open      Authorization-Lifetime +       send STR   Discon
|               Auth-Grace-Period expires on
|               access device
|
|     Open      Session-Timeout Expires on     send STR   Discon
|               Access Device
 
--> draft-mobileip should specify the actions of both the server and
the access device when the MIP-Key-Lifetime AVP expires.  Presumably
the access device should send an STR, while the server quietly cleans
out the session.
 
--> should draft-mobileip (and the other application
drafts) add an "Authorization Session State Machine" and
"Accounting Session State Machine" section, indicating
application-specific extensions to the base state machine?
e.g. mobileip-08 would add
"Open  Key-Lifetime Expires on Access Device  send STR Discon"
 
--> is there a "grace period" for the MIP-Key-Lifetime AVP? if so, is
a new MIP-Key-Lifetime-Grace-Period AVP needed?
             
|  base-08 Section 8.4 "Session Termination" says:
|
|  A Diameter server also MUST clean up resources when the Session-
|  Timeout expires, or when the Authorization-Lifetime and the Auth-
|  Grace-Period AVPs expires without receipt of a re-authorization
|  request, regardless of whether an STR for that session is received.
|  The access device is not expected to provide service beyond the
|  expiration of these timers; thus, expiration of either of these
|  timers implies that the access device may have unexpectedly shut
|  down.
|
|  base-08 Section 8.9 "Authorization-Lifetime AVP" says:
|
|  If both this AVP and the Session-Timeout AVP are present in a
|  message, the value of the latter MUST NOT be smaller than the
|  Authorization-Lifetime AVP.
|
|  This AVP MAY be provided by the client as a hint of the maximum
|  lifetime that it is willing to accept. However, the server MAY return
|  a value that is equal to, or smaller, than the one provided by the
|  client.
 
--> Must MIP-Key-Lifetime AVP be <= Session-Timeout ?
 
--> Can the client send the MIP-Key-Lifetime AVP to the AAAH as
some sort of hint?
 
|  base-08 Section 8.12 "Re-Auth-Request-Type AVP" says:
|
|  The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and
|  is included in application-specific auth answers to inform the client
|  of the action expected upon expiration of the Authorization-Lifetime.
|  The following values are defined:
|
|     AUTHORIZE_ONLY             0
|        An authorization only re-auth is expected upon expiration of
|        the Authorization-Lifetime. This is the default value if the
|        AVP is not present in answer messages that include the
|        Authorization-Lifetime.
|
|     AUTHORIZE_AUTHENTICATE     1
|        An authentication and authorization re-auth is expected upon
|        expiration of the Authorization-Lifetime.
 
--> Should the server convey something akin to the above, to tell the
client what action to take upon MIP-Key-Lifetime expiration?  Can the
client request a "key refresh"?
 
Bob K.

---

From: Tony Johansson <[email-masked]>
Date: Fri, 22 Feb 2002 16:19:29 -0800

Hello Bob and All,

To decouple the Authorization-Lifetime and the key lifetime was introduced in
issue 186.  I've been trying to come up with an explanation to issue 186 and
what Bob states below, but the more I think about this the more unsure I
become to why we need this decoupling.

In the Base we have the Session-Timeout AVP , which contains the maximum
number of seconds of service to be provided to
the user before termination of the session, and the the
Authorization-Lifetime AVP, which contains the maximum number of seconds
before a re-auth needs to be done. Unless I've missed something here, I don't
see why we introduced a third timer in MIP appl.

When the keys are distributed to the MN, FA and HA we also tell the number of
seconds they all are valid that, to me, also applies the number of seconds
before re-auth, which is exactly the definition of the Authorization-Lifetime
AVP.

Comments please.

/Tony

---

From: Johan Johansson <[email-masked]>
Date: Sat, 23 Feb 2002 01:47:26 +0000

>become to why we need this decoupling.
What was the reason that the key lifetime was introduced in the first 
place? Was it to provide the possibility to allow some keys to live 
longer than others? I have a vague memory of a vague impression through 
Fredrik (any misinterpretations are of course mine) that this might be 
the case. Unfortunately this would mean that key life times need to be 
multiples of the mobile node's keys since the client can't make a 
spontaneous reauthentication and so I think the decision was made to 
move it from the individual keys and only allow one per AMA.

>before a re-auth needs to be done.
>
Is it correct that 4s before Session-Timeout we could reauthenticate and 
get an authorization life time of 300s?

j