Alex/Jari
> > After your reply, my expectations confirm more and more that this is
> > very much of AAA and PANA issue, and much less of securing the ND.
> > Simple intuition tells me that if AAA and PANA can help authenticate
> > the access, then ND is subsequently secured.
>
Not necessarily. As the ND threats draft I believe mentions, a fully
authenticated
node might decide to start playing the trickster, snooping traffic, etc.
Cryptographic
security on ND messaging helps prevent that. All AAA does is
authenticate at the
time of network entry, that the host is authorized to use the network,
and provide
the host with whatever it needs to have access. It doesn't prevent
subsequent
misbehavior.
> > If I were to work on securing ND, I would leave the key obtention
> > behind (be it AAA, IKE/JFK/LBJ, ABK, CGA) and concentrate on how AH
> > and ESP are applied to ND messages and see with that how to solve
the
> > threat draft. I might have a look into that, probably.
>
> This on the other hand is an interesting issue. We may be
> able to separate the keying part from the protection part,
> even if the keying would take place without an infrastructure
> as in CGA. E.g., a router could use the host's public CGA
> key to encrypt a session key which it sends to the host, and
> the host uses this key in AH/ESP to protect actual signaling.
>
> But the modifications necessary before ESP works well
> enough for ND are pretty interesting. The basic problem
> we need to deal with manually keyed ESP is dst address
> as a pointer to the SA; this needs to change if manual
> keying is to be used. Another basic problem is inability
> to use *any* IP-based key management protocol (including
> IKE) due to chicken-and-egg effect. A third problem
> is that when the ND protection gets host specific -
> as it should - we need some way of indicating individual
> SAs.
>
Right, these are all issues the ABK draft was written
to help solve, and CGAs might work here as well.
> Also, the above discussion indicates that if we are
> to secure ND, we need a requirements document first.
> It isn't clear to me whether everyone agrees that we
> need infrastructureless, infrastructure-based, manually
> keyed etc.
>
Good point.
My intention here is fairly practical. Public access 802.11 networks
today
are very insecure on the last hop. If you look at Mobile Star's
(an 802.11 public access network provider) page, they basically say
you are on your own as far as security goes. For purposes of
providing the kind of secure wireless ISP service that people
expect, I think we need a solution to this problem, and fairly
soon.
So, while I want a good, scalable technical solution, I am
not particularly religious about what form the solution takes.
ABKs have a kind of technical elegance IMHO (as do CGAs
in their own way), but if we can make things work with
IPsec then I'm certainly not averse to doing it.
jak
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
