Subject: RE: Location of authentication agent

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 15 Apr 2002 15:21:24 +0200

Alper,

  > > => More than the ones in the scenarios draft?
  > > Namely: Load sharing, limited free access and 
  > > payment after a certain point..etc
  > 
  > We should look closer at these scenarios.
  > 
  > For example, in limited free access and payment after a certain
  > point scenario, where would you put the authentication agent? It'd
  > be good to take a look at the model and required interactions among
  > protocol entities.

=> I would assume that you would put it at the border
of the 'free'/'don't care' zone. But this was intentionally
removed from the draft. We can certainly (and we should)
discuss it on the mailing list, but I hope we don't 
do a full circle and include solutions in the 
draft again. 

  > While this scenario can be supported by separation of 
  > authentication agent
  > from the enforcement point, does it really need that? Or 
  > can we achive the 
  > same when two are co-located? What component of this 
  > scenario requires
  > the separation? 

=> Well, it depends on which case you refer to. In the
load sharing case you need to separate the access
enforcement from the authentication, otherwise you 
need to authenticate twice (unless there is some 
protocol running between the default routers). 
I don't know if someone has a better idea on how
to do this. Of course the other question is: Why 
does it matter? That is, what is the cost incurred
in separating the 2 entities and running SNMP/COPS/midcom ...etc
between them ?
I like to think of it as starting from the most flexible
solution, then trading flexibility for cost. 
There were concerns raised during the meeting about 
the 'extra cost' associated with this separation, 
but I didn't get a clear idea about where this cost
would come from. So maybe now is a good time to
discuss this. 

Hesham

---

From: subir Das <[email-masked]>
Date: Mon, 15 Apr 2002 11:14:54 -0400

Hesham,

> protocol running between the default routers).

If I understand you correctly, following are the abstractions:

For limited free access:

PANA Client ------- Edge device -------- Enforcement Point/PANA Agent
------ PANA Server

For Load sharing:

PANA Client ------ Edge Device/Enforcement Point ---- PANA Agent ------
PANA Server 

Subir

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 15 Apr 2002 17:42:55 -0700

> to do this. Of course the other question is: Why 

So, the idea is to build a hierarchy of authentication.
If the PaC gets authenticated to a PAA behind a set of
access routers, we expect the PAA to automatically 
distribute state to all access routers within this PaC's reach.

Can't we achive the same by relying on the local AAA server
even when PAA is co-located with the access routers? Local
AAA server is behind PAAs and it can distribute similar state
upon the PaC getting authenticated.

> in separating the 2 entities and running SNMP/COPS/midcom ...etc

We'd need to identify what that transport is, and make sure it satisfies
all the needs of access authentication (transporting keys?)

The PAA discovery would be different as well, and harder I suspect.

> solution, then trading flexibility for cost. 

A better approach is starting simple and seeing if it can
serve the need. If not, expending on it, IMO.

> would come from. So maybe now is a good time to

Yes, this is a good time to discuss the issue as we are
clarifying the scope.

alper

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 16 Apr 2002 04:00:35 -0700 (PDT)

I think one of the good arguments I heard is that PAA
server and access router are separate entities anyway.
Even if they reside on the same device, logically they
will be separate entities.

Second, we already have a good real world examaple on
how it happened with PPP, Radius and NASes. We could
authenticate users on the NAS/BRAS themselves, but
that didn't stop people from having external Radius
and even PEPs.

Thirdly, when you have several access routers or
policy point,s is better to have a single entity
distributing policies than configuring on each one. As
I said, even if the PAA reside on one of the access
routers it would need to download the policies to the
other ones, so we would be back to the same situation.

finally, the limited free/premium content/walled
garden and other variations imply sometimes more than
on AR anyway since in some of these configurations the
content does not even belong to the same entity that
provides transport services.

regards,

Reinaldo

> Yes, this is a good time to discuss the issue as we

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

---

From: John Schnizlein <[email-masked]>
Date: Tue, 16 Apr 2002 08:41:19 -0400

>that didn't stop people from having external Radius

This analogy with the separation of NAS from Authentication Server (AS)
does not fit the proposed separation of the authentication agent (AA)
from the enforcement point (EP). The AS is separate in both cases.
With PPP the EP and AA are co-located within the NAS.

What is being proposed is yet another separation into EP, AA, then
(optionally) an AS using Internet-Standard AAA protocols. If the EP
and AA are separated, a protocol with complete analysis if its
security considerations, robustness, etc. will have to be defined in
addition to the PANA (which appears to reach only from the client to
the AA). The argument for arbitrary location of the AA (on the edge?)
seems to be for flexibility, although the cost tradeoff for this
flexibility is not yet clear. Is it clear that the EP needs to be 
at the edge?

John

---

From: subir Das <[email-masked]>
Date: Tue, 16 Apr 2002 09:32:17 -0400

John,

> With PPP the EP and AA are co-located within the NAS.

   Agreed.
> the AA). 

  It is not clear to me why you say so. Let me describe what I 
  understand:

Case I:

  +-------+           +-------+         +--------+      +-------+
  | Pac   |-----------|  Edge |---------| EP/AA  |------|  AS   |
  + ------+           +-------+         +--------+      +-------+

     <---------------- PANA --------------->

Case II:

 +-------+           +-------+         +--------+      +-------+
 | Pac   |-----------|Edge/EP |--------|   AA   |------|  AS   |
 + ------+           +-------+         +--------+      +-------+

     <-------------- PANA ---------------->
                                 
                          <----- (2)?? -----> 

If PANA can handle case I, it should be able to handle case II 
assuming that we know how to discover AA. Of course for case II, 
we have to design/specify protocol(2) which is between AA and EP. 
So I don't understand why you think that we have to define another 
protocol between Pac and AA apart from PANA. Am I missing something? 

>The argument for arbitrary location of the AA (on the edge?)
> flexibility is not yet clear. 

  I agree. 

  Subir

---

From: John Schnizlein <[email-masked]>
Date: Tue, 16 Apr 2002 10:37:44 -0400

Subir,

You did not miss anything. What your diagram shows as protocol (2)
EP - AA could easily be the additional protocol. I did not mean to 
say where this protocol would be. The other possibility is between 
the PANA client and the EP.

You raise another issue that the proposed separation entails: choosing
which of the three parties should have protocols between them. This
choice should not be arbitrary either. The complexity of the separation
is starting to emerge as we identify the issues that would require
analysis.

John

---

From: subir Das <[email-masked]>
Date: Tue, 16 Apr 2002 10:06:02 -0400

John,

> is starting to emerge as we identify the issues that would require

  Completely agree with you. We have to clearly specify the model and 
  understand the complexity. I think most of us agree with the fact that 
  the existing model is simple but don't want to rule out other 
  possibilities as well. 

  Subir

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Apr 2002 09:23:38 -0700

> upon the PaC getting authenticated.

Yes, exactly! This is the point that some of us have been
trying to make in and since Minneapolis.

The PAA is duplicating a lot of functionality of the AAA server.
Keeping the PAA co-located with the access router and 
distributing the AAA server is more robust, and is consistent
with the current NAS architecture.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Apr 2002 09:41:17 -0700

> will be separate entities.

Much as I don't like alot about the way telephony people do network
architecture and protocol design, one of the good things they do is make
a distinction between a functional architecture and a network
architecture. The functional architecture groups functionality into
functional entities, the network architecture groups functional entites
into boxes and defines interfaces between them on which protocols are
defined. Like all good things, this distinction can be taken to
unhealthy extremes, but I've found it a good starting point in many
cases.

What you are saying is that a PAA is a functional entity that can reside
in a variety of network entities. What we are discussing and, to a
certain extent disagreeing about, is in what network entity the PAA
should reside.

> other ones, so we would be back to the same situation.

So what you are saying is that sticking with the existing NAS
architecture will still allow multiple
access routers on the link to be accommodated.

> provides transport services.

I'm not quite sure I understand what this has to do with separating the
PAA into a separate network entity that can reside anywhere in the
access network or keeping it as part of the default access router on the
link.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Apr 2002 09:54:29 -0700

> flexibility is not yet clear. Is it clear that the EP needs to be

This seems farily clear to me. The intent of the EP is to allow or deny
service to a particular host. The first opportunity for gating this
behavior is the access router. It makes logical sense to gate at that
point.

Is there some reason why one would want to gate further back in the
network?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Apr 2002 10:16:25 -0700

Subir,

There needs to be a protocol from PAA to EP to transfer enforcement
decisions. Whether that's PANA or another protocol is another question.

But this problem can be avoided entirely by making the PAA and EP be the
same. Thus, PANA becomes very simple: a network layer transport for AAA
between host and edge.

            jak

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 16 Apr 2002 10:20:41 -0700 (PDT)

I'm not sure I agree the EP should be only on the
edge. That the example I was trying to articulate (but
probably due to my coffee intake I used a lousy
wording). 

There are situation where after the AR you have some
walled garden content which have (each of them) their
own EP. 

regards,

Reinaldo

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Apr 2002 10:20:09 -0700

>   the existing model is simple but don't want to rule out other

In fact, I think we do want to rule out other possibilities. A more
complex architecture provides more opportunity for security attacks, a
longer design time, etc. If nobody can come up with a compelling reason
why the current NAS architecture is insufficient, then I don't see any
reason for changing it. What's the point of complicating things if there
is no significant benefit?

            jak

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 16 Apr 2002 10:24:14 -0700 (PDT)

I agree we need another protocol, but the protocol is
already out there. Actually we have more than one to
choose from: COPS, midcom, snmp...

Let me ask this. Can't we say PAA and EP can be on
different devices or on the same device. If they are
on different devices you need a protocol between them,
which is out of scope. period.

regards,

Reinaldo

--- James Kempf <[email-masked]> wrote:
> > > This analogy with the separation of NAS from
> Authentication Server
> (AS)
> > > does not fit the proposed separation of the
> authentication agent
> (AA)

---

From: subir Das <[email-masked]>
Date: Tue, 16 Apr 2002 12:36:38 -0400

ALper/James,

Are we assuming that there will be always a AAA infrastructure at the
back end? 
Can you draw your model and explain? 

Subir

---

From: subir Das <[email-masked]>
Date: Tue, 16 Apr 2002 12:56:26 -0400

James,

> is no significant benefit?

  Instead of debating like this, we should come up with some concrete 
  points. May I request you to provide some analysis why you think this
is 
  very complex? We will also try. 

   Subir

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Apr 2002 11:08:32 -0700

Subir,

It need not be RADIUS or Diameter but there does need to be something.

The other issue is whether an implementation could bundle AAA/AA/EP in
one entity.

            jak

PS: I'm not very good at text drawings, sorry.

----- Original Message -----
From: "subir Das" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Alper E. YEGIN" <[email-masked]>; "Hesham Soliman (ERA)"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, April 16, 2002 9:36 AM
Subject: Re: Location of authentication agent

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Apr 2002 11:23:50 -0700

>   very complex? We will also try.

OK, here's one point.

Putting the PAA back in the network widens the scope of topology for DoS
attacks. If the PAA is at the first hop, the only place a DoS attack can
come from is on that link. Because the geographic span of the link is
limited, it is much easier to find and disconnect the perpetrator than
if the topological span is across multiple subnets, and thus across a
larger geographic range.

In addition, an attack on a PAA at the first hop disables access to just
that link. An attack on a PAA back in the network could potentially
disable access to an entire segment of the ISPs network, or potentially
the entire network if the ISP has one PAA for the entire network.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Apr 2002 11:37:30 -0700

> Is there some way to decide if rough consensus is to
> make enabling walled gardens out of scope, if not
> an explicit non-goal of the WG?
>

Technically, what do you think enabling walled gardens involves?

IMHO, I see PANA as a simple network transport for EAP between the host
and the edge. At the edge, the AAA protocol (Radius, Diameter) takes
over. What actually happens at the edge depends on what is transported
in the EAP and the ensuing AAA exchange, and thus out of scope of the
WG.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Apr 2002 11:38:04 -0700

Agree!

            jak

----- Original Message -----
From: "John Schnizlein" <[email-masked]>
To: "subir Das" <[email-masked]>
Cc: "James Kempf" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, April 16, 2002 11:01 AM
Subject: Re: Location of authentication agent

> I don't think such a categorical assumption is necessary.
> Instead, the simple model of co-locating the EP and AA, with
> any separation of function that is necessary accomplished
> through the Internet-Standard AAA protocol, is superior to
> requiring yet another protocol required by yet another separation.
>
> John
>
> At 12:36 PM 4/16/2002, subir Das wrote:
>
> >Are we assuming that there will be always a AAA infrastructure
> >at the back end?
> >
> >James Kempf wrote:
> >>

---

From: John Schnizlein <[email-masked]>
Date: Tue, 16 Apr 2002 13:51:47 -0400

This is just the sort of thing I was afraid of.
We should find out as soon as possible if the WG
wants PANA to be designed so that it supports
walled gardens. The walled garden is about as
antithetical to the fundamental principles of the
Internet as anything I have seen.

It is worth noting that the references to enabling
walled gardens, which received negative comment early
in the URP - BURP phase of BOFs was removed in the
charter that got past the IESG. If this support again
becomes part of the goal of the WG, the IESG should
again be asked to review its status.

John

At 01:20 PM 4/16/2002, Reinaldo Penno wrote:
>edge... 
>> >Is it clear that the EP needs to be at the edge?
>> 
>> behavior is the access router. 
>> It makes logical sense to gate at that point.
>> 
>> Is there some reason why one would want to gate
>> further back in the network?

---

From: John Schnizlein <[email-masked]>
Date: Tue, 16 Apr 2002 14:01:18 -0400

John

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Apr 2002 10:59:24 -0700

> walled garden content which have (each of them) their

I don't think anybody is arguing that content not have it's own EP. That
is done today when you want to get into Web sites. There is work such as
MS Passport/Liberty for single sign on in that area, but it is
application level.

The issue here is network access and perhaps access to specific
ports/protocols (e.g. SIP, HTTP). This is a much larger granularity.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Apr 2002 11:01:32 -0700

> which is out of scope. period.

Why? I don't see any compelling reason for this. Opening up the
architecture in this way sets it up for new kinds of security threats
and other complications.  I don't think we should go through the
difficulty of having to completely redo the network access design unless
there are compelling reasons.

            jak

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 16 Apr 2002 12:15:48 -0700 (PDT)

Hello James,

the associated protocol is out of scope and also any
associted security threats. It wouldn't make sense to
say the protocol is out of scope but not the security
threats.

I'm curious, can you think of an IETF architecture
where an assolciaed protocol is declared out of scope
but people felt the need to deal with the security
threats of this out of scopr protocol? IMHO this seems
weird.

regards,

Reinaldo

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 16 Apr 2002 12:17:23 -0700 (PDT)

I do not agree this access is application level
oriented. Today there are examples where the access is
controlled on a src ip base to a given subnet.

regards,

Reinaldo

---

From: John Schnizlein <[email-masked]>
Date: Tue, 16 Apr 2002 15:16:58 -0400

IMHO you clipped the context out of my earlier message.
I recovered it and copied it at the end of this message.
But maybe you wanted a different perspective..

In exactly the same way that the IETF decided not to consider
technical modification to Internet protocols to serve the
purpose of enabling "wire tapping", it should not be necessary
to outline technically what enabling walled gardens involves
before deciding that supporting walled gardens is not a goal.

I understand walled gardens as Internet-like networks that
do not subscribe to the principle of interconnected networks,
but instead have a goal of capturing subscribers within an
area in which only the provider's content is available.
Because this abstract summary is undoubtedly insufficiently
clear, an example might help.

WAP has been seen as a protocol development that encouraged
Internet-like walled gardens for cell-phone use. Instead of
connecting the packet-transmission capability of some 
cell-phones to the Internet, some service providers limited 
the Web-like access to only their own servers. Market forces 
appeared to demand gateways from these walled gardens to other 
content servers on the Internet, but occasionally with modified
content.

One of the ideas that was prominent in early discussions of 
URP, then BURP, which has become PANA, was that subscribers
would have unrestricted access to a walled garden portion of the
Internet, but would need to authenticate and start billing in
order to escape the walled garden and reach into the Internet.

One of the technical implications drawn from the 
escape-walled-garden model was that the access control would not 
be at the edge between subscribers and Internet-like communication, 
but instead the edge would be defined between walled gardens. 
This "requirement" seems to have re-emerged when the question of
locating the EP at the edge was asked explicitly.

Making support for walled gardens a non-goal of the WG (instead
of just removing it from the documents reviewed by the IESG)
would allow finding other reasons (if they exist) for locating
the EP somewhere other than the edge, but would avoid renewing
this goal now that the WG has been chartered without it.

John

---

From: John Schnizlein <[email-masked]>
Date: Tue, 16 Apr 2002 14:15:25 -0400

Choosing an already specified protocol to perform the linkage
between the parts that result from splitting the NAS function
into EP and AA does not resolve the problem of analyzing its
operation and security. The candidates you suggested: COPS,
midcom, snmp, have their own problems for distributing 
configuration parameters with access-control implications.

Specifying that another new protocol is required, with its 
details declared out of scope, as part of resolving PANA
seems to recurse on the generation of protocols. Not good.

John

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Apr 2002 13:29:57 -0700

> threats of this out of scopr protocol? IMHO this seems

If  the WG is to propose a major architectural change, then neither the
associated protocol nor the security is out of scope.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Apr 2002 13:31:57 -0700

> controlled on a src ip base to a given subnet.

Examples?

Like I said, if you are talking about opening a hole for a protocol/port
like a firewall, then I think there is a place for it. If you are
talking about charging for content, then PANA is probably not a good
solution.

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 16 Apr 2002 19:14:42 -0700

Subir,

With AAA as the backend:

PaC --- EP/PAA ------- AAAlocal ------- AAAhome

So, now we'd like to separate EP from PAA, so that
PAA can control more than one EP:

PaC --- EP --+- PAA ------- AAAlocal ------- AAAhome
                           |
    --- EP --+

Why can't we do the same by relying on the AAAlocal:

PaC --- EP/PAA --+--- AAAlocal ------- AAAhome
                                   |
    --- EP/PAA --+

This was the scenario using AAA as the backend. But
we can replace "AAAlocal and AAAhome" with any other
authentication backend. AAA is not a must.

alper

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 17 Apr 2002 05:38:57 -0700 (PDT)

Hello James,

I only consider a major archiotectural change anything
that changes the PANA protocol or entities per se.

Saying in a certain scenario you need to use another
protocol which is out of scope I do not consider a
major architectural change.

Reinaldo

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 17 Apr 2002 09:49:42 -0400

> authentication backend. AAA is not a must.

We cannot always expect for all the AAA signaling messages 
originated from those PAAs to pass through the same AAAlocal 
when there are multiple AAA local proxies, since AAA message 
routing topology can be arbitrary.  In an extreme case, 
two AAA messages originated from different PAAs can take 
completely different paths to reach the AAAhome.

Yoshihiro Ohba

---

From: subir Das <[email-masked]>
Date: Wed, 17 Apr 2002 09:30:53 -0400

Alper,

> "Alper E. YEGIN" wrote:

 For limited free access we are discussing the following model: 
 
   PaC--- Edge ---- EP/PAA----- AS 

  According to my understanding, your model and our model are 
  same in this case. 

For Load sharing:

  PaC---- Edge/EP --- PAA ----- AS
                       | 
     ---- Edge/EP------+
  
  This is similar to your top one. So for load sharing people 
  have different views. Please see Yoshihiro's mail why  
  cann't we achieve the usage scenario as described when EP and 
  PAA are colocated?
  
  Now we have to figure out which model brings complexity.
  Apparently, I don't see much cost difference: you 
  need N PAAs, but other people need one PAA and another 
  protocol. Of course we have to consider the security aspects. 
  As I mentioned earlier, without having a better understanding
  we should not rule out other options at this time. I agree that we 
  should solve the simple case first, however, if we know additional 
  requirements at the beginning it will be always better IMHO.

  Subir

> Cc: "Alper E. YEGIN" <[email-masked]>; "Hesham Soliman
> (ERA)" <[email-masked]>; <[email-masked]>

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 17 Apr 2002 12:22:32 -0700

Yoshihiro,

> completely different paths to reach the AAAhome.

But, this is a network design issue. If the operator wants
the feature (one authentication, multiple EPs updated), then
the network should be designed in a hierarchical way.

Same with the separate EP and AA. All the EPs that need
to be updated simultaneously need to be (logically) attached to the
same AA. 

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 17 Apr 2002 16:32:06 -0400

OK.  My next question is, can the proposed solution be supported
without changing the current Diameter NASREQ application
specification?  If it can't, I would say that it does not fit the
existing NAS model and thus would be problematic.

Yoshihiro Ohba

---

From: "James Kempf" <[email-masked]>
Date: Thu, 18 Apr 2002 08:13:30 -0700

Splitting the NAS into AA and EP is a major architectural
change. If such a change is to be proposed, then it is
incumbent upon the working group to work out all
the details of the change, so that the interoperability
and security implications are well known before the
result is standardized. It is not acceptable to make
the change, declare part of the
consequences of the change (i.e. the protocol
and security between PAA and EP) out of
scope, then just work on the other part.

            jak

----- Original Message -----
From: "Reinaldo Penno" <[email-masked]>
To: "James Kempf" <[email-masked]>; "subir Das"
<[email-masked]>; "John Schnizlein" <[email-masked]>
Cc: "Reinaldo Penno" <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 17, 2002 5:38 AM
Subject: Re: Location of authentication agent

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 19 Apr 2002 07:25:12 -0700 (PDT)

The protocol is not between PAA and EP.

The protocol is between the COPS/midcom process
running on the same device and the EP. 

regards,

Reinaldo

--- James Kempf <[email-masked]> wrote:
> > > > the associated protocol is out of scope and
> also
> > > any
> > > > associted security threats. It wouldn't make
> sense
> > > to
> > > > where an assolciaed protocol is declared out
> of
> > > scope
> > > > threats of this out of scopr protocol? IMHO
> this
> > > seems
> > > > weird.
> > > >
> > >

---

From: "James Kempf" <[email-masked]>
Date: Fri, 19 Apr 2002 06:41:25 -0700

I think NASREQ must be doable with PANA, but I don't think all of what
PANA does must be doable with NASREQ. One could extend NASREQ or write a
different extension.

            jak

----- Original Message -----
From: "Yoshihiro Ohba" <[email-masked]>
To: "Alper E. YEGIN" <[email-masked]>
Cc: "Yoshihiro Ohba" <[email-masked]>; "subir Das"
<[email-masked]>; "James Kempf"
<[email-masked]>; "Hesham Soliman (ERA)"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, April 17, 2002 1:32 PM
Subject: Re: Location of authentication agent