Subject: Re: Re: PAA Discovery

From: Paal Engelstad <[email-masked]>
Date: Mon, 11 Feb 2002 20:46:45 +0100

James,

> > James did not only say we should not use extensions to RA. If I
> understood his comment correctly we should also refrain from developping
> protocol-specific mechanisms.  I expect this warning includes most of
> the transport mechansms. Did I understand you correctly, James?
> 
> Yes, that is correct.

Good. I will try to get this point clearly communicated in the next version of the draft. In general, I will try to reflect the PAA discovery discussion on the list, and perhaps include some conclusions from the work of the DNS Discovery team as Hesham proposed.
 
> > - Perhaps with exception of Anicasted Authentication request?
> >
> 
> 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" ;-)

> 
> > 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?

> 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...;-)

Paal

>             jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Feb 2002 13:09:25 -0800

> 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 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.

> 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.

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?

            jak