Subject: security requirements

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 18 Feb 2002 17:01:22 -0800

Folks,

Here is an attempt to cover security aspect of PANA
in the req. draft. First two are already from the draft.
Please provide comments and propose requirements.

Cheers,

- Authentication and encryption of data traffic sent to and from 
an  authenticated PaC is outside the scope of PANA. Providing 
a complete secure network access solution by also securing 
router discovery [RDISC], neighbor discovery [NDISC], and 
address resolution protocols [ARP] is outside the scope as well.

- PANA MUST be robust against a class of DoS attacks such as 
blind masquerade attacks through IP spoofing that swamp the PAA 
in spending much resources and prevent legitimate clients' attempts 
of network access. The required robustness is no worse than that 
for TCP SYN attack.

- PANA MUST provide protection against replay attacks on both 
PaCs and PAAs.

- PANA MUST not assume a secure channel between the PaC and 
the PAA. PANA MUST be able to provide authentication even in the 
networks which are not protected against eavesdroping and spoofing.

- Location privacy is outside the scope.

- PANA authentication MUST include the DI presented to the PAA, 
so that the DI is not spoofed prior to verification and should not be 
altered by the PaC after the verification. Protecting PaC against DI theft 
is outside the scope of PANA.

- anything on key distribution through PANA and using these keys with 
link-layer mechanisms or IPsec???

alper

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 20 Feb 2002 00:45:29 -0800 (PST)

Hello Alper,

is good that we are trying to augment and tackle the
security issues around PANA.

Reading the thread between James, Paal, you and others
it seems this requirements here are not touching one
critical qiuestion which is the integrity of the DI
and its implications as the "authentication jumpstart"

other comments inline...

> eavesdroping and spoofing.

I'm confused about this one. the first phrase is okay,
but the second is strange. The whole point behind
security is that networks are susceptible to
eavesdroping and spoofing. 

Sorry, it's kind of late and I read this 3 times
(;-)but in the case of "networks which are not
protected against eavesdroping and spoofing." is clear
that we MUST provide authentication. Is there a case
where we shouldn't?

> is outside the scope of PANA.

I'm not sure I follow this Alper. How the DI is going
to presented to the PAA in the first place? Is it
out-of-scope?

"that the DI is not spoofed prior to verification and
should not be altered by the PaC after the
verification"

I couldn't understand this phrase...Could you expand a
little bit?

> link-layer mechanisms or IPsec???

thanks,

Reinaldo

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 20 Feb 2002 16:05:13 -0800

Reinaldo,

> and its implications as the "authentication jumpstart"

Inclusion of DI in authentication was meant for that.. Does it
not help? If not, what would you recommend?

> eavesdroping and spoofing.

Yes, and I'm just re-iterating this. So that, for example,
people don't distribute  session keys in clear, and they
authenticate important pieces of protocol packets...
So, PANA should work even if your neighbors can see
your packets, and can fabricate any packet they like.

> that we MUST provide authentication. Is there a case

This just says PANA MUST not assume link is spoof-free
and eavesdropping-free.

> to presented to the PAA in the first place?

Well, specific solution has to give an answer to this.
One solution might say that it must be in the payload and
authentication hash includes all the bits in the payload.

> Is it

saying there must be a way to carry DI is in the scope of the
requirements. Saying how exactly it is done is not.

> I couldn't understand this phrase...Could you expand a

If the DI is not included in the authentication hash, a malicious node can
capture this request and replace the DI with a different one. We want
to prevent this spoofing.

Or, once the PANA exchange is completed, we don't want to give the freedom
of using any DI to the PaC unless PaC does another round of authentication
for
that specific DI. So, PaC is authorized to use that DI.

alper

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 21 Feb 2002 15:36:46 -0800 (PST)

> not help? If not, what would you recommend?

No, I think it helps. What we need to amke sure is its
integrity.

> > > in the req. draft. First two are already from
> the
> > > draft.
> > > - Authentication and encryption of data traffic
> sent
> > > to and from
> > > an  authenticated PaC is outside the scope of
> PANA.
> > > Providing
> > > a complete secure network access solution by
> also
> > > securing
> > > address resolution protocols [ARP] is outside
> the
> > > scope as well.
> > >
> > > - PANA MUST be robust against a class of DoS
> attacks
> > > such as
> > > blind masquerade attacks through IP spoofing
> that
> > > swamp the PAA
> > > in spending much resources and prevent
> legitimate
> > > clients' attempts
> > > - PANA MUST not assume a secure channel between
> the
> > > PaC and
> > > the PAA. PANA MUST be able to provide
> authentication
> > > even in the

read you phrase again..you say that "PANA MUST be able
to provide authentication even in the networks which
are not protected against eavesdroping and spoofing"

I think it should "especially" instead of "even"

Also s/the//

> > > - PANA authentication MUST include the DI
> presented
> > > to the PAA,
> > > so that the DI is not spoofed prior to
> verification
> > > and should not be

I see, I suggest we replace the original text with
this one you just wrote. It's mich clearer.

thanks,

Reinaldo