Subject: Re: RE: Solutions ...

From: Paal Engelstad <[email-masked]>
Date: Tue, 15 Jan 2002 23:27:30 +0100

Erik,

Comments inline,

> 
> Fra: Erik Nordmark <[email-masked]>
> Dato: 2002/01/15 Tue PM 08:22:39 CET
> Til: Paal Engelstad <[email-masked]>
> CC: Erik Nordmark <[email-masked]>,  [email-masked]
> Tema: RE: Solutions ...
> 
> 
> > In my mind, authentication (e.g. in order to authorize network access or
> > not) and policy enforcement (e.g. discard packets of unauthenticated &
> > unauthorized users) are separate matters. PAA is only concerned with the
> > authentication part, while enforcement of network access, on the other hand,
> > is handled by firewalls, security gateways, and other things that are
> > outside the scope of PANA WG. Therefore, as long as PAA has a means to
> > communicate with this equipment (e.g. a MIDCOM or a proprietary protocol),
> > and can be reached by roaming nodes, PAA can be localized anywhere.
> 
> I suspect there are scalability issues with having single PAA serving a very
> large number of devices. For large networks there might also be
> issues in the PAA always knowing the topology so that it can determine from
> the device' IP address where in the network it is attached (so that it knows
> what enforcement points it need to update once a device is authenticated).
> 

These are good points, but they don't convince me that an authenticator must be located on the AR. If the PAA can be located anywhere in the access domain, it should not be too difficult to design a protocol that allows roaming hosts to discover a list of redundant PAAs to choose from.

> > Furthermore, address assignment cannot be enforced by the AR in my opinion.
> > In fact, a malicious node can use whatever IP address it would like - but
> > some IP addresses would not be useful if there is for example a firewall
> > installed on the AR or CR. If address assignment cannot be enforced anyway,
> > why not assume that the roaming node always has aquired an IP address prior
> > to authenticating?
> 
> If the temporary addresses in RFC 3041 are viewed as required one could make
> a much stronger statement in the IPv6 space; that PANA must allow
> hosts to use RFC 3041 without the provider being able to prevent their use.
> 

I hope and expect that security requirements will comprise a significant part of the requirement document that is currently taking form. 

Identity hiding of roaming clients seems to be a security issue of increasing importance, and I think it is appropriate if RFC 3041 is mentioned in the requirement document, either as a requirement by itself or as an example of a means to accommodate identity hiding.

Paal

(BTW: Isn't identity hiding also relevant with regard to using NAIs? A visited domain does not need to know the exact identity of the user; it needs to know the user realm and an opaque user id that the authentication authorithy in the home-realm is able to recognize/decrypt.)

>    Erik

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 15 Jan 2002 17:53:31 -0500

> (BTW: Isn't identity hiding also relevant with regard to using NAIs? A visited domain does not need to know the exact identity of the user; it needs to know the user realm and an opaque user id tha…

Support for RFC3041 was also discussed about six months ago.
(see below, and www.toshiba.com/tari/issues.txt) 

I did not include this in the usage scenarios draft because 
it would relate to the notion of "authorization token" which is 
now out of the scope of PANA.

-------------------------------------------------------------------------
Issue #8: Is it possible for BURP to support changing IP address?

It should be possible, at least to support IPv6 Privacy Extention
defined in RFC 3041.  

The user identifier may be exposed on the subnet when a user initially
registers to RA.  However, this does not necessarily mean that
anonymity by using RFC 3041 is compromised.  Even BURP is used with
RFC 3041, the user can still be anonymous from others.  This is
explained by the following example:

  (i)  After successful initial registration, Client does not use the
       user identifier but using an anonymous user identifier (e.g., a
       permission token) , where the anonymous identifier is
       associated with the user identifier and securely assigned in a
       way that only the RA can know the association,

  AND 

  (ii) After successful initial registration, Client changes the IP
       address.

  Note that if the network is doing access control based on IP
  address, it will be needed to inform the RA of the IP address change
  by using the anonymous identifier.

> >    Erik

Yoshihiro Ohba

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 16 Jan 2002 10:57:04 +0100 (CET)

> (BTW: Isn't identity hiding also relevant with regard to using NAIs? A
> visited domain does not need to know the exact identity of the user; it
> needs to know the user realm and an opaque user id that the authentication
> authorithy in the home-realm is able to recognize/decrypt.)

This is a good issue to bring up.

Today with roaming between ISPs using PPP I think the NAI is
a fixed username and the realm, but the NAI format can be used to 
carry something else that the home realm understands.

I don't know if PANA will push for the need to specify something like this
thus it would be good to have a discussion whether or not it should be
part of the PANA requirements.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 16 Jan 2002 11:04:49 +0100 (CET)

> now out of the scope of PANA.

I think we had some discussion about tokens where I said I didn't understand
how they could provide any security hence doesn't make sense.

But this doesn't mean that the identity of the "session" (or whatever term
makes more sense) need to be tied to an IP address.

For instance, it could be tied to an IP address prefix (like a /64 for a PAN)
or it could be tied to a e.g. a symmetric crypto key that is created 
during the initial authentication and later used for local reauthentication.
(The above are just example of mechanisms - I'm not pushing for
any particular mechanism.)

  Erik

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 16 Jan 2002 09:35:17 -0500

> any particular mechanism.)

If I understand your point correctly, authorization token per packet
is out of scope, but authorization/anonymity token per "session" could
be in scope, right?

Yoshihiro Ohba

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 16 Jan 2002 22:11:12 +0100 (CET)

> is out of scope, but authorization/anonymity token per "session" could

Close but no cigarr :-)

The "scope" question is about the scope of the problem to solve and
not about the aspects of the solution.
Thus if some "token" per packet solve (part of) the problem (in a secure manner
of course) it would be one approach to look at.

Previously I had made some statement on the mailing list that I didn't
understand how such a thing could work (securely) and nobody clued me in
at the time.

  Erik

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 16 Jan 2002 16:55:51 -0500

> of course) it would be one approach to look at.

Okay.

> understand how such a thing could work (securely) and nobody clued me in

The problem on this issue would be related to whether a stable
identifier used for initial authentication could be bound to a temporal
and randomized identifier or token in a secure manner.

Entering solution spece a little bit, EAP itself does not seem to be
able to support carrying such binding information.  So I think
non-EAP based, some special message exchange over IPsec or other secured 
channel would be neccesary to exchange the binding information.

Yoshihiro Ohba

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 17 Jan 2002 00:30:38 +0100 (CET)

> and randomized identifier or token in a secure manner.

Establishing the token in a secure manner is the easy part I think.

The issue is how to, on a multiaccess link, prevent an attacker from
snooping the token from the data packets and the either
 - using that token on the same link at the same time as the real device
 - using that token on the link after the legitimate device has left the link
 - taking the token to another link/AR and using it there

In order to handle the above type of threats the token can't be carried
in the clear in the data packets as far as I can tell.

  Erik

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 16 Jan 2002 19:35:33 -0500

> in the clear in the data packets as far as I can tell.

So using token per-packet basis seems to be a difficult problem to
solve.  

Next thing to discuss would be whether using token per-"session" basis
is difficult or not.  I mean using token only for periodical or
on-demand re-authentication, not for each data packet.  In this case,
the token could be carried in clear text within EAP Request-Identity
message (of course if we assume EAP is used for re-authentication).
Spoofing the token would fail unless the attacker knows the shared
secret used for re-authentication.

Yoshihiro Ohba

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 17 Jan 2002 16:08:48 +0200

Erik,

This goes completely to the solution space (and therefore
may be inappropriate), but may be interesting anyhow.

 > In order to handle the above type of threats the token can't be
 > carried in the clear in the data packets as far as I can tell.

One idea (and just an idea) that have been locally floating
here for some time is to use some S/Key kind of mechanism
on per-packet level.  That is, when the client authenticates
to PAA, it gets a random number R_0.  The client then
calculates a number of sequentive hashes, i.e.
   H_1 = hash(R_0)
   H_2 = hash(H_1)
   H_i = hash(H_i-1)
   H_N = hash(H_N-1)

After that, when sending a packet, it simply includes
an ID, the sequence number i and the corresponding hash code
H_i to the packet.  The firewall/whatever keeps a state
corresponding state <ID, i, H_i>.  When it gets a packet
with the matching ID, it checks that j in the packet is
smaller than i in the state.  Normally j = i-1.  The
firewall then computes hash(H_j) and checks that it
matches with the H_i in the database, and records the
new values.

If computing a hash for each a packet is considered to be
too expensive, an alternative is require that the next
hash code is sent every 10th packet or so.

One additional benefit of this scheme is that it also
requires the client to re-authenticate whenever it is about
to run out of the hash codes.

--Pekka Nikander