Subject: Re: [mobile-ip] Authentication Data as a BU suboption

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 01 Aug 2001 13:47:11 -0700

from Mohan's mail

> From RFC2409,
> 
>    Phase 2 is where Security Associations are negotiated on behalf of
>    services such as IPsec or any other service which needs key material
>    and/or parameter negotiation. "Quick Mode" accomplishes a phase 2
>    exchange. "Quick Mode" MUST ONLY be used in phase 2. 
> 

the main thing in the above paragraph is "or any other service which 
needs key material".

IKE is for key exchange. IKE/BAKE/PKI/AAA can all establish
a key between two nodes. extract the security association from 
the database, store it in the binding update list and use 
it to authenticate the BU. the SA is stored in the binding
cache entry in case of the CN.

i am not an expert at IKE either. but that doest prevent me
from going into the SPD database (mobile ip module), extract
the SA and store it in the binding update list.

the mobile ip module has the all the information it needs
(key, spi, algorithm). it calculate the authentication 
checksum as soon as the BU option is created.

vijay

"Hesham Soliman (ERA)" wrote:
> 
> i never eliminated IKE. when you need strong authentication
> gets the keys using IKE. but instead of adding an authentication
> header, you send the authentication checksum as a BU suboption.
> 
> => My understanding was that the current BU format
> does not allow the use of IKE. I'm not an expert
> on -ike by any means but this was voiced on the list
> by a few people and there was no opposition to this
> opinion.
> 
> Hesham
> 
> "Hesham Soliman (ERA)" wrote:
> >
> > I like authentication data as a BU suboption. this
> > authentication data protects the BU option and the
> > home address option alone. nothing else. draft-14
> > gives a cleaner solution for authenticating BU's IMO.
> >
> > advantages
> > ----------
> >
> > 1. we dont have to get a new next header value for the
> > destination options header containing the BU
> >
> > => That would add zero cost.
> >
> > 2. we dont have to modify the ipsec selectors
> >
> > => Again zero (or insignificant) cost
> >
> > 3. we dont have to protect the whole packet
> >
> > => Why is that an advantage ?
> >
> > 4. we dont have bother about the traffic flows between
> > the MN and the CN.
> >
> > => We don't have to anyway if we stop piggybacking.
> >
> > 5. we can piggyback BU's. somebody asked a question if
> > BU's are sent often. YES, BUs could be sent often to
> > refresh the bindings. its not necessary the home agents
> > agree to very large lifetimes for BUs. and BUs are sent
> > to everybody in your binding update list everytime you
> > move.
> >
> > 6. we dont have to store the security association for
> > protecting the BU in the ipsec database. lookup is
> > expensive. it could be stored in the binding update
> > list entries. you already have access to the key.
> >
> > => Do you really see a lookup time as a critical issue ?
> > I'm not sure that it would be, even for real time
> > data. Are there any figures on how long it takes ?
> >
> > 7. authentication checksum calculation can be done
> > very early (ie when the BU is being formed). in the
> > current implementations you pull the packet out from
> > the ip6_output function, calculate the checksum and
> > put it out again in the ip6_output function. this is
> > because you cant calculate the checksum until the
> > whole packet has been formed.
> >
> > => Sure, but what's the added value in doing it
> > earlier ?
> >
> > One advantage is that you might like to allow for
> > IKE when strong authentication is needed. Why
> > eliminate that option ?
> >
> > Hesham

---

From: Michael Thomas <[email-masked]>
Date: Sun, 5 Aug 2001 08:37:34 -0700 (PDT)

> cache entry in case of the CN.

   BAKE & friends can only establish a key if they do
   an ephemeral Diffie Hellman, which according to the 
   analysis draft is discouraged. As I've said earlier,
   since we have the opportunity to have soft state
   with weak authorization, we should seize the
   opportunity since it makes life much, much more
   robust on many fronts.

	     Mike