Subject: Re: Re: PAA Discovery

From: Paal Engelstad <[email-masked]>
Date: Tue, 12 Feb 2002 0:14:40 +0100

James,

> > > If someone wants to propose an anycast mechanism, then I think they
> > > better be able to make a good case for it.
> > > It is another protocol-specific method.
> >
> > Agreed. Nevertheless, I though a anicasted "Identity Request" might be
> easily accommodated (assuming for example EAP-over-ICMP) - if we make "a
> good case for it" ;-)
> >
> 
> Are you proposing anycasting the PANA message itself or the discovery
> request? If the former, I have no
> objections, in fact, it looks like an interesting use of anycast.

I just want to point out that I am not proposing a solution. I am proposing a possible solution. We can of course not settle on a discovery mechanism before we have seen the PANA protocol.
 
Having that said, yes, IMO if we are not going to create our own mechanisms, this is the closest we get among the transport mechanisms. It saves messaging and round-trip times. But anycasting is not a panacea, of course (e.g. RFC 1546).

If we anycast a discovery message, on the other hand (which would be more like creating our own discovery protocol - I know you're against it), PAAs probably need to know about other PAAs. (PAAs could of course run secure SLP in the back, but I guess this part would out of scope anyway.)

> > >
> > > > I am still concerned with the security aspects of the remaining
> > > alternatives; SLP, DNS, and DHCP. I assume that security aspects
> will be
> > > especially important criteria for PANA.
> > > >
> > >
> > > I'm still not clear why there are any additional security problems
> here
> > > beyond those involved in using EAP
> > > over PPP or 802.1x. Actually, it seems
> > > like the security would be better
> > > since a preconfigured IPSEC
> > > security association could kick in as soon as the IP traffic
> >
> > I think I am a little confused right here. Which kind of IP traffic
> are you referring to in this case?
> >
> 
> The presumably unicast PANA traffic. If there is an IPSEC SA with the
> PANA server, then
> there should be no problem.

Agreed. It would definitely solve the problem with e.g. eavesdropping, using encryption.

However, I am focusing on different security aspects right here. My concern is that un-authenticated PaCs will use a discovery mechanism to discover PAAs. The same discovery mechanism should not allow them to legally discover other information.

So, what I am asking: Can SLP, DNS or DHCP be configured so that anyone could discover PAAs, while only those with SAs (i.e. authenticated PaCs) may discover other services/information? Pretty trivial question...

Paal

> 
> > > with the
> > > PAA came up. Naturally, if such
> > > a SA didn't exist, it becomes more tricky.
> >
> > To facilitate network management, we want to locate network
> information about a number of services in a centralized information base
> (be it SLP, DNS, DHCP etc). Un-authenticated PaCs with no SAs are only
> authorized access to information about one service (namely PANA
> Authentication service i.e. PAAs). Authenticated PaCs, on the other
> hand, are authorized access to information about all different kinds of
> services. Can you give me a little more details on how you are
> discriminating access by "kicking in an SA". It is probably a trivial
> matter. Sorry for being slow, I did't get it...;-)
> >
> 
> What I mean is, if the traffic with the PANA server should be secured by
> IPSEC if there is a security association.
> One could also require an IKE exchange if a security association didn't
> exist.This may be too heavyweight, however.
> 

Agreed. However I am not focusing on authenticated hosts not revealing information about the network. I am focusing on un-authenticated hosts getting more information about the network than they necessarily need.

> But this still doesn't answer my question about why the security problem
> is any different from 802.1x or EAP over
> PPP. In those cases, the AAA traffic to the 802 switch or access point
> or PPP end point is unauthenticated and unencrypted (unless you count
> WEP as encryption). This means that someone snooping the initial EAP
> exchange
> could learn a lot about the host, like, for example ,the NAI. It is not
> clear without further analysis if this information
> would suffice to give the snooper an attack advantage, i.e. whether this
> is just a privacy problem or a security
> problem. You seem to feel that there is a security problem, which means
> that a snooper could mount an
> attack, if I interpret your remarks correctly. Can you clarify?

Well. Security includes a lot of things, so let's discuss one thing at the time, and address eavesdropping in another thread :-) 

Thanks,
Paal

>             jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Feb 2002 17:15:36 -0800

> However, I am focusing on different security aspects right here. My
concern is that un-authenticated PaCs will use a discovery mechanism to
discover PAAs. The same discovery mechanism should not allow them to
legally discover other information.
>
> So, what I am asking: Can SLP, DNS or DHCP be configured so that
anyone could discover PAAs, while only those with SAs (i.e.
authenticated PaCs) may discover other services/information? Pretty
trivial question...

Whether or not they can discover any more information is a function of
the PANA protocol, not
the discovery method. They may be able to discover some information
about the PAA, if,
for example, it has attributes that distinguish one PAA from another,
but that should all
be public information.

            jak