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

From: "Pat R. Calhoun" <[email-masked]>
Date: Fri, 22 Feb 2002 18:29:06 -0800

If memory serves, Glen Z can provide more info, but tying the
authorization lifetime to the key lifetime were considered
inappropriate. It is possible to have a key that spans many
authorization lifetimes (and the protocol does allow requesting
authorization without a key).

However, if memory serves this issue spawned from the NASREQ
document.

PatC

- -----Original Message-----
From: Tony Johansson [mailto:[email-masked]] 
Sent: Friday, February 22, 2002 4:19 PM
To: Bob Kopacz
Cc: aaa-wg
Subject: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP

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

Bob Kopacz wrote:

> 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: Sat, 23 Feb 2002 13:11:23 -0800

Hi Pat,

"Pat R. Calhoun" wrote:

>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

But, in the AAA Registration Keys for Mobile IP, which we are dependent
on, you can only tell the mobile one timer (the Lifetime). The Lifetime
AAA Registration Keys for Mobile IP indicates the duration of time (in
seconds) for which the MN-FA and MN-HA keys are valid. When the keys
expires the MN must re-auth, so seen from the MN the authorization
lifetime and the key lifetime is very much the same thing. Right?

So, if we want the session keys to span many authorization lifetimes
don't we need to make the MN more aware? I mean, as the AAA Registration
Keys for Mobile IP draft are define right now the MN would expect to get
new keys when the Lifetime timer expires, which may not at all be true
if we say that the session keys may span over many authorization
lifetimes.

Regards,

/Tony

> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
>
> iQA/AwUBPHb+cTN1fXKoxmisEQKHpACfZ3o3rm/fqEBL9DyJ7GmcTyT4ep0AoMwA
> vkpp6LB9mVPym6M5ORY/ESQd
> =0Eq7
> -----END PGP SIGNATURE-----