Subject: RE: [seamoby] The two-year-ago token

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 15 Jun 2001 11:14:51 +0200

# hi

Hello folks,

If I remember right, the token went under the nickname of "blob"
in those days.  When I try to apply the token theory to context
transfer, I get the following:

- Mobile supplies token
- New access router validates token
  == how does it prevent against another node "prematurely"
       using the token?
  == how does it prevent replay?
  == does the same token work for all nearby access routers?
- New access router asks old access router for context features
- Old access router sends stuff
- ...

# one possible use of a token (ticket) would be:
# the mobile node A when authenticating to a AR1 would obtain a
# session key k(a,ar1) and a 
# token {TS,TT,k(a,ar1),ID(a),ID(ar1)}k(ar) whereby
# TS is a timestamp, TT is the maximum lifetime and k(a,ar1) is the 
# session key used between the client and the ar1. the key k(ar)
# shared between all ARs. 
#
# when a mobile node moves to a new AR (AR2) he would use old session
# key k(a,ar1) to build an authenticator 
# {CurrentTimestamp,...}k(a,ar1) and sends this authenticator together
# with the received ticket to the new AR (AR2). 
# 
# AR2 is able to decrypt the received token(ticket) to receive the 
# embedded session key k(a,ar1). Using the session key he is able 
# to verify the authenticator and authenticate the user. 
# (AR2 has to do more verification steps which are omitted here!)

   == how does it prevent replay?
# yes - only a authenticated user knows the session key and is able to 
# build the authenticator.

  == does the same token work for all nearby access routers?
# it depends how many routers share the same key k(ar).

# what do you think?

# ciao
# hannes

---

From: James Kempf <[email-masked]>
Date: Fri, 15 Jun 2001 09:02:28 -0700 (PDT)

Another advantage is reduction in the amount of PDP/PEP traffic
needed to authorize QoS after the mobile has moved. If the PEP can
make the decision based  on the blob, this traffic can be eliminated,
considerably speeding up reestablishing QoS on the new subnet.

		jak
		
>Delivered-To: [email-masked]
>Date: Fri, 15 Jun 2001 05:26:27 -0700
>From: Pat Calhoun <[email-masked]>
>To: Charlie Perkins <[email-masked]>
>Cc: Pat Calhoun <[email-masked]>, Arthur Ross <[email-masked]>, 
"'seamoby'" <[email-masked]>
>Subject: Re: [seamoby] The two-year-ago token
>Mail-Followup-To: Charlie Perkins <[email-masked]>, Pat Calhoun 
<[email-masked]>, Arthur Ross <[email-masked]>, 'seamoby' 
<[email-masked]>
>Content-Disposition: inline
>User-Agent: Mutt/1.2.5i
>
>On Thu, Jun 14, 2001 at 05:58:52PM -0700, Charlie Perkins wrote:
>> in those days.  
>correct.
>> When I try to apply the token theory to context
>No, the access router provides the token to the mobile. The token includes
>the amount of time the user has been authorized to have access, the features
>the mobile has been authorized to use, an encrypted session key that the
>access router uses to secure messages between itself and the mobile, a 
timestamp,
>expiration time, and is digitally signed.
>
>correct.
>What does this mean?!? Once a token has been provided to the mobile,
>it isn't premature....
>
>The token has a lifetime, which SHOULD be the same as the authorized
>amount of the time the user may access the network (this, btw, is
>returned by AAA).
>
>yes. There is a need for all access routers to be able to verify the
>validity of the token. This could require that they all share a Private
>key, or some other mechanism on the back end that would allow them to
>share the decrypted version of the token.
>
>correct, and this is based on the info contained in the token.
>
>which it agreed to do, based on the features in the token.
>
>> - ...
>...
>
>> In this scenario, I don't see much advantage because the
>> old access router could more easily check some credentials
>> produced by the mobile node as part of its request to get
>> stuff from the old access router.  Or maybe it's all a matter
>> of definition, and a "blob" and a "token" should be treated
>> as variations of some "credential data", and the only point
>> is which access router verifies it.  Or we might be worried
>> about how much data has to go over the air.
>
>I believe that the concern at the time was the amount of data
>over the air, but this still significantly reduces the amount
>of time it would take to construct all of this information if
>AAA had to be contacted. 
>
>Keep in mind, though, that the primary use for the blob at the
>time was to carry session keys across access routers to eliminate
>the need to re-establish an SA between the MN and the FA. This
>was done prior to the context transfer work, and if CT exists,
>then it most likely is much more efficient to simply CT this
>information across ARs, instead of have the mobile supply it.
>
>PatC