Subject: [MOBILE-IP] routing optimization authentication

From: Gao Qing <[email-masked]>
Date: Thu, 12 Aug 1999 22:02:54 +0800

Dear Emad,

You've made your idea clear to us this time.
Actually I also came up with a similar idea.

I suggest the pre-established SAs are: MN-HA, FA-CA1, HA-CA2. (CA1 and CA2
are
respectively certification authorities of FA and HA. there is also an SA
between CA1
and CA2 as they both belong to the same CA structure.).

EXPLANARATON:

In MIP, it is compulsory that MN-HA authenticate each other because of
remote
redirection. MN-FA and FA-HA authentication are optional.

However, if we only perform MN-HA authentication, we are very likely to take
a risk
of being exposed to a hostile FA. A hostile FA can perform denial-of-service
attack to a MN or
forward the MN's registration request to a host other than the MN's HA.
Therefore, it
is also necessary to authenticate the FA.

It is impractical that all of the three security associations (MN-HA, FA-HA,
MN-FA) be
established in advance. The reason is that the MN could roam over a large
area and the number
of FAs it may get service from could be very large, thus with the MIP
standard solution based on
secret-key crypto-mechanism, such a senario would involve too many keys be
distributed between
the entity pairs. The difficulty of key management would severely impair the
scalability of MIP.

There are two methods dealing the MIP distributed authentication.
The first is based on secret-key authentication with the help of AAA
(Authentication, Authorization and Accounting)
servers which are borrowed from RADIUS (Remote Authentication Dial-in User
Service). The AAAH (Home AAA server) responds for generating three keys for
the three entity pairs of the tripartite authentication and distributing
these keys
with the help of the AAAF (Foreign AAA server). This scheme solved the
scalability
problem. However, it requires on-the-fly key generation and delivery.
The more communicants involved, the more significant overhead and delay will
be introduced.

The second method is based on public-key
authentication(draft-jacobs-mobileip-pki-auth-02.txt).
 It is based on X.509 digital certificates, digital signatures and
public-key mechanism.
This scheme solves the scalability problem of MIP without on-the-fly
key generation. However, it is more computationally intensive than the
secret-key
based method. Moreover, all the three entities need to verify each other's
public key contained in
the certificate. This may introduce significant delay especially for the
MN-FA pair since
they are very likely to belong to different Certification Authorities due to
the possibly large geographic
distance originally between their domain.

Taking into consideration that usually, the bandwidth of wireless networks
are much
more limited and the transmission error rate is much higher than those in
the wired networks,
it is desirable to optimize and reduce the number of messages sent
over the wireless link. From the viewpoint of an MN, it is also better to
have as little computation load as possible.
We proposed an authentication protocol based on both the secret-key
and public-key cryptographic mechanisms.
We keep applying the secret-key authentication between the MN and the HA.
This
is reasonable since the number of MNs an HA handles is usually limited and
they can be viewed as belonging to the same administrative domain.
Public-key based authentication is applied to the FA and the HA to
improve the scalability of the standard authentication protocol.
There is no direct authentication between the FA and the MN, but an implicit
one.
This is because the HA can in fact verify the identity of the MN to the FA
and vice
versa, provided that the two-way authentication between the two pairs, MN-HA
and FA-HA, is successfully performed. In other words, if the HA does not
trust either the MN or the FA, the authentication will fail and so will the
registration. In this way, the MN and FA can be viewed as implicitly
realizing the two-way authentication between each other.
Therefore, without on-the-fly key generation and
with one pair direct auththentication skipped, this scheme is scalable and
efficient.

PS. Though in mathematical sense, it is said that trust is not transitive:
A*B and B*C <> A*C,
I think in real world, different situation have different requirement, and
in MIP, trust relationship
to this degree is able to meet the security requirement.

regards,

Qing

-----Original Message-----
From: Emad Qaddoura [mailto:[email-masked]]
Sent: Wednesday, August 11, 1999 6:04 AM
To: [email-masked]
Subject: Re: [MOBILE-IP] routing optimization authentication

Dear Gao,

        To start, there was a typo error in my earlier statement "The HA
does not send a successful reply if the FA is trusted by the HA resulting in
the MN trusting the FA" it should read:

"The HA does send a successful reply if the FA is trusted by the HA
resulting in the MN trusting the FA"

        Additional comments are below.

Regards,
Emad Qaddoura, 972-684-2705, esn (444)

> -----Original Message-----
> From: Gao Qing [mailto:[email-masked]]
> Sent: Tuesday, August 10, 1999 8:57 PM
> To: [email-masked]
> Subject: [MOBILE-IP] routing optimization authentication
>
>
> Hi Emad,
>
> In your previous email, you said:
> >         In addition, once the registration reply is
> received by the MN,
> then
> > the new FA is authenticated. The HA does not send a
> successful reply if
> the
> > FA is trusted by the HA resulting in the MN trusting the FA.
>
>
> Could you please tell me in your scheme which on earth entity
> pairs need
> to perform authentication, both HA-newFA and MN-newFA, or
> either of them?

In MIP, the required SA is between the MN and HA. Others between (MN and
FA), (HA and FA) are optional extensions.

Now, there is some concern about the MN establishing a new security
association during a handoff due to the delay introduced. However, what I
was suggesting is, one way for the MN to trust the new FA is:

        o The MN and HA have a SA,
        o The newFA and HA have a SA,
        o Then, the MN can trust the newFA without a direct SA between the
MN and FA.

I was not making new SAs. The mandatory and optional extensions are in 2002.

What would be your suggested SAs?

>
> Is there any basis (standard or draft) for your second
> statement of trust
> relationship derivation?

What do you see wrong in it?

>
> Why do you say that the HA does not send a successful reply when the
> following assumption holds?
>
Please see corrected statement above.

> Thanks & regards,
> Qing

---

From: Emad Qaddoura <[email-masked]>
Date: Thu, 12 Aug 1999 15:25:22 -0500

Hello Gao,

> Sent: Thursday, August 12, 1999 9:03 AM

I totally agree. We made the same point in the draft by Mohamed Khalil and
Liem Le, "draft-mkhalil-mobileip-optim-sec-00.txt"

> the entity pairs. The difficulty of key management would

My personal view is, it may not be practical to setup these static
relationship. The MN may visit many domains and for it to have static
relationship with all of the FAs, to allow explicit trust, would be painful
to manage.

However, if we assume that the implicit trust between the FA by the MN
resulting due to the FA trusting the HA and the MN trusting the HA, the
complexity of the static SAs may be simplified. But, any solution should
allow for dynamic trust relationship as it would be impossible to have all
SAs static.

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 12 Aug 1999 14:08:17 -0700

>> distance originally between their domain.

I certainly cannot dispute the fact that a full blown PKI has scaling advantages,
but it also has deployment problems. The reality of the fact is that the global PKI
is not here yet, and may be here 5+ years from now.

That said, simply using a PKI is not quite sufficient. A service provider is probably
willing to authenticate a user given a certificate, but it certainly wants *some*
proof from the home domain that the services provided will be paid for. So AAA is more
than just for authentication, it also provides authorization and accounting. There is
some work going on in regards to authorization certificates, but these are assumed to
be longer lived than what we need here, because the overhead of creating such a certificate
is very high. I would think that such a certificate could be employed to allow a user to
print to a certain class of printers within a network, but not in this environment.

So we end up with AAA anyways. The home domain will *have* to authenticate the user, and
will perform the authorization. Generating the keying information is not that much of a
drain on resources, but encrypting the keys *could* be. Today, people scale their AAA
(read RADIUS) infrastructure by deploying more and higher end systems. The network provider
that runs their AAA infrastructure on a single 66MHz pc is in for a world of trouble.

> with one pair direct auththentication skipped, this scheme is

Lastly, your comment about MN-FA authentication not being necessary raises an issue. My
feeling was that local hand-off could be performed by allowing the Foreign Agents to
authenticate the Mobile Node, without having to inform the home agent. Of course I am
implying a hierarchical network here, and the movement is within a local network.
If the MN-FA does not exist, then how could a Foreign-Agent securely handle hand-offs?

PatC

---

From: Vipul Gupta <[email-masked]>
Date: Thu, 12 Aug 1999 14:35:02 -0700

> From: Patrice Calhoun <[email-masked]>

> is not here yet, and may be here 5+ years from now.

  I don't see why the use of public-key style authentication in the
  context of Mobile IP has to require a "global PKI". As Steve Kent
  has also mentioned several times on the IPSec mailing list, deploying
  PKI in a closed system isn't hard (it is more a mental block than
  anything else).

  Also consider the fact that there are several thousand (if not more)
  HTTPS servers operating today using public-key technology.

  vipul

---

From: Vipul Gupta <[email-masked]>
Date: Thu, 12 Aug 1999 17:00:36 -0700

> From: [email-masked] (Patrice Calhoun)

> Because with the current plans of CDMA deployment, it really isn't a "closed"
> network.
>
> PatC

  Can you elaborate? I don't see the effort involved in setting up a
  shared key between AAA servers belonging to different carriers
  as being much different from having them cross certify each others
  root key (irrespective of whether this roaming agreement happens
  directly or indirectly through a broker).

  vipul

---

From: "n. asokan" <[email-masked]>
Date: Fri, 13 Aug 1999 14:32:49 +0300

Hi,

[email-masked] (EXT Gao Qing) writes:
[...]
> is also necessary to authenticate the FA.

What exactly is the threat and how will FA->HA authentication help
with that?

If the threat is denial of service, FA->HA authentication
won't help (FA can simply not forward any packets, including the
registration request).

If the threat is FA having access to MN's data, it is probably best
dealt with using upper layer confidentiality protection.

In any case, to avoid 'hostile FAs', FA->HA authentication alone isn't
enough.  HA has to have some way of deciding whether an FA is
'hostile' (black lists, white lists, whatever).  This probably implies
more infrastructure.

[...]

> The more communicants involved, the more significant overhead and delay will

Actually, use of shared-key systems does not have to necessarily imply
having an entity like AAAH generate keys on the fly and distribute it
to MN: short term/temporary keys can be derived from a long term key.
E.g., in your example above, if the MN shares a long term key K with
the AAAH, then the key between MN and a given FA can be derived as a
function of K, the identity of the FA, and possibly some transient
information (like the current time).  That way, the AAAH does not have
to generate a key and convey it to MN and FA but compute it and convey
it only to the FA (via AAAF). I.e., MN can already compute this key
and use it to compute and attach an authenticator in its registration
request.  FA will be able to verify the authenticator when it receives
the key from AAAH.  No additional flows between FA and MN are
necessary.

[...]

Regards,
- Asokan

--
N. Asokan, Communication Systems Lab, Nokia Research Center, Helsinki

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 13 Aug 1999 06:13:27 -0700

>> Vipul,
>> The number of relationships in the AAA case is one per peer, in the case of
>the
>> PKI we are talking about a cert for each mobile node and mobility agent. One
>
>Pat,
>
>If we assume a shared key between the mobile and the HA and use certs
>for HA and FA then the scalability may not be problem. We may not need
>FA-MN auth in most cases (if MN-HA and FA-HA exist).

See my previous response to this in regards to local mobility in a hierarchical
network.

>
>
>> also has to consider the CRL infrastructure that need to be in place to
>support
>> that kind of network.
>>
>> I could be wrong but setting up a relationship with a broker, and getting a
>single
>> cert for the AAA server seems much less complex. Furthermore, no CRL is
>required since
>> the broker participates in the AA/A, and therefore would deny any
>> requests for/from
>
>Are you assuming that the AAA borker is also the CA (Certificate Authority)?

I think most of my AAA documents are pretty clear about this. A broker can easily
act as a CA, issuing certs to the AAA servers that are part of the roaming
consortium.

PatC

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 13 Aug 1999 11:13:28 -0500

>Because with the current plans of CDMA deployment, it really isn't a
"closed"

The current CDMA deployment is among a few major service providers
and can be *considered* a "Closed" network for the purpose of
discussion here. The organizations that intend on deploying Mobile IP
need to take a serious look at the option of having a closed PKI
system and the fact that it is very much a feasible solution. I agree
with Vipul's thought here,  that deployment of Mobile IP by a group of
service providers who can agree and thereby have a closed PKI
system. Global roaming in the future will require supporting global
PKI. But by the time we get to that point I believe we will have such
an infrastructure in place.

-Basavaraj

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 13 Aug 1999 11:57:54 -0500

>>>>> but it also has deployment problems. The reality of the fact is that
the
>>>>global PKI
>The current AAA proposals that I've made allow for the broker to
>issue certificates to all roaming partners, but not in the scale that
>you are talking about. In fact, no cross-certs are necessary, unless
>inter-broker mobility is allowed.
>
>As I stated earlier, even if that is the case the AAAF/AAAH are still
needed
>to make on-the-fly authorization decisions. A certificate alone will not be
>sufficient for a foreign service provider to provide service to a mobile
node.

Pat,

So the broker is a CA and issues certs to the roaming partners? What I
am refering to is the case where you have a few service providers who
agree to cross certify their CAs as a result of roaming agreements
between them. The PKI managed by a service provider could issue certs
to the mobility agents. I am not refering to brokers at all. Well I
guess you could still have a broker concept to minimize the number of
associations between roaming partners, but in a small subset it does
not really matter.

In order to provide service to a foreign MN the visiting network needs
to be assured of receiving payment. Since the FA and HA *may* authenticate
each other via certs, receiving a successful registration reply should
be sufficient (in my opinion). What other authorization info (in the
present context) needs to be provided to the visiting network in order
to provide service. Of course you will need the capability of
generating accounting records and that's where the *A* of AAA may fit
in. Maybe I am missing your point Pat....If I am please clarify.

-Raj

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 13 Aug 1999 10:04:23 -0700

>in. Maybe I am missing your point Pat....If I am please clarify.

In the current ROAMOPS model, local authentication and authorization is
simply not sufficient. The foreign domains normally wants to get some
assurances that payment will occur as a result of the services offered.

If a foreign network authenticates a user, should it simply assume that
by sending accounting records it will get paid? Not at all. It needs to
get authorization from the home network that it is willing to pay for
the service. Furthermore, the home domain can have additional restrictions
on the service that is to be offered to the mobile node that cannot really
be expressed in the certificate.

All of the work done in ROAMOPS, and the work on the Authorization requirements
have pretty much made this clear in all of their documents. If you are
proposing that roaming using Mobile-IP is vastly different from the
normaly business model in use today, then the WG should make that clear.

PatC

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 13 Aug 1999 13:59:53 -0500

----snip snip----------

>assurances that payment will occur as a result of the services offered.

I did not intend to say that authentication and authorization be done
locally.
Authentication is still being done by the home network and the
assurance that the foreign domain needs for services offered is
received in the form of a succesful registration resonse message. The
reason that the foreign domain trusts this response message is because
of it's ability to authenticate this message (roaming agreement
between the foreign and home network and the existence of a PKI in
these networks.......previous discussion).

>be expressed in the certificate.

Refer to the comments above (the foreign network is not the one
authenticating the user). Services and authorization for what services
a Mobile user can avail of in a foreign/visited domain is definitely
not going to be expressed in a certificate. If you look at the
cellular model the foreign domain (VLR) receives a version of the Mobile
users profile from the HLR which allows the visited network to
determine what services the user is authorized for. My point is that I
am not expecting authorization for services to be "expressed in a
certificate".

>All of the work done in ROAMOPS, and the work on the Authorization
>requirements have pretty much made this clear in all of their
>documents. If you are proposing that roaming using Mobile-IP is vastly
>different from the normaly business model in use today, then the WG
>should make that clear.
>
>PatC
>

The roaming model for Mobile IP is not (need not be) any different
than what is currently in existence today or has been proposed by
ROAMOPS. I think we were discussing the same problem with  different
contexts here.

-Raj

---

From: Gao Qing <[email-masked]>
Date: Mon, 16 Aug 1999 17:45:23 +0800

-----Original Message-----
From: Patrice Calhoun [mailto:[email-masked]]
Sent: Thursday, August 12, 1999 2:08 PM
To: [email-masked]
Subject: Re: [MOBILE-IP] routing optimization authentication

>PatC

When assuming a hierarchical network, I agree with you. This architecture
implys
that FA is a trusted part of the local access network and FA has an SA with
HA.

However, when there is no such hierarchical network, for example, in the
internet,
the FA is NOT previously trusted by either the access network or the HA (no
roaming
agreement established in advance). In this senario, the FA acts passively.
Once it has seen the successful registration reply from the HA (implying
the HA successfully authenticated the MN and the FA) and has authenticated
the
HA successfully, the FA can derive that FA implicitly authenticated(thus can
trust)
MN counting on the HA. And once the MN has seen the successful
registration reply from the FA, it can derive that MN implicitly
authenticated(thus can
trust) FA counting on the HA.

By performing asymmetric HA-FA authentication, at least we can be sure that
an
hostile FA can not deny in the future what he had done.

Qing

---

From: Gao Qing <[email-masked]>
Date: Mon, 16 Aug 1999 18:08:44 +0800

Hi,

-----Original Message-----
From: n. asokan [mailto:[email-masked]]
Sent: Friday, August 13, 1999 4:33 AM
To: [email-masked]
Subject: Re: [MOBILE-IP] routing optimization authentication

>won't help (FA can simply not forward any packets, including the
At least we can provide non-repudiation with asymmetric FA-HA
authentication.

>dealt with using upper layer confidentiality protection.
I agree. We only deal with entity authentication here.

>'hostile' (black lists, white lists, whatever).  This probably implies
Well, just like the CRL, it *may* be managed by the CAs. The HA should
only verify the certificate of the FA, thus the public key of the FA. With
that public key, the HA can verify the FA's signature appended to the
registration request. The result also provides the HA with 'non-repudiation
of
origin'.

>the key from AAAH.  No additional flows between FA and MN are

But the HA still has to wait for the registration request and generate and
distribute a key for the FA, right? It can not avoid introducing significant

overhead and delay.

Moreover, the current time at the MN won't be conform to that at the HA.
They generate the key at different time.

Qing

---

From: "n. asokan" <[email-masked]>
Date: Tue, 17 Aug 1999 09:01:06 +0300

Hi Qing,

> At least we can provide non-repudiation with asymmetric FA-HA

I agree that asymmetric key cryptosystems in general enable nice
features. But I still don't see the rationale for FA->HA
authentication/non-repudiation.  What threat are you addressing when
you think of the non-repudiation service for FA->HA? (E.g., is there
some scenario when FA will later try to deny that it forwarded a
registration request from the MN?).

[...]
> registration request. The result also provides the HA with 'non-repudiation

Well, it may not be as simple as that.  Consider the case when MN
sends a registration request for CoA X.  The only threat that seems to
justify FA->HA authentication is the following: MN is actually in the
X network; but it has been deemed a 'hostile network' by home domain
policy.  Here, HA needs a list of bad guys (or good guys). It is
unlikely that CAs can manage this list, since it is likely to be based
on domain-specific policy: note that FA will have a perfectly valid
certificate (or other means of authentication) corresponding to X;
just that MN's home domain policy does not allow MN to roam into the X
network.

   -> For black lists, FA->HA authentication is an overkill.  HA can
      simply reject the registration request based on CoA.
   -> For white lists, FA->HA authentication makes sense if we don't
      trust the security of the routing infrastructure (but we have
      bigger problems if routing infrastructure is compromised!).

Seems to me that FA->HA authentication based on IP address of FA is of
little use.

FAAA->HAAA authentication, based on a label from some other name
space than IP addresses may be useful. But perhaps this is beyond
scope for mobile-IP?

Supporting FA->HA authentication is probably no big deal.  For my own
edification, I would really like to know what rationales people
had in mind for the FA->HA authentication.

[...]
> distribute a key for the FA, right? It can not avoid introducing significant

Yes, except that the key does not have to be sent (e.g., over the
wireless channel) to the MN.

When the MN does not have a key pair (as I thought you were
suggesting), HA has to wait anyway for the registration request, and
respond confirmation to FA and MN, right?  The overhead of
'generating' a key as I mentioned earlier (e.g., a single keyed hash)
or transporting it to FA (there is already an HA->FA flow) is not
significant.  The advantage is that in the end, there is an MN-FA
security association which is useful.

Even when MN does have a key pair, I think typically you cannot avoid
at least one on-line check with the home domain when an MN wanders in
for the first time into a foreign domain.  This is needed to ensure
the solvency of the user (i.e., that the foreign domain will get paid
for its services).  In general, asymmetric key based systems can
reduce the number of flows only when no on-line authorization check is
required.

[...]

HA doesn't use its own time, but the time value used by the MN (which
MN can securely convey to the HA using the long term MN-HA shared
key).  It also does not have to be 'time' but any time-varying factor;
or it can be left out altogether (with the consequence that MN-FA key
will always be the same until the MN-HA key is changed).  By the way,
these are rather common techniques from the early '90s (if not before)
KryptoKnight suite of protocols.  For example, see "Authentication of
mobile users" by Samfat et al in IEEE Network, 8(2):26-35, March/April
1994.

Regards,
- Asokan

---

From: Gao Qing <[email-masked]>
Date: Thu, 19 Aug 1999 12:35:32 +0800

Hi, Asokan

>registration request from the MN?).

OK. In the current internet, FA may just be a node providing MIP function.
It may not be intergrated with the access network closely. Thus, any node
that can provide FA function could broadcast Agent Advertisement and
detunnel packages. The situation is: A hostile FA can take over an newly
arrived MN from an existing legal FA. If the hostile FA is not
authenticated,
it can pass the MIP registration easily and make the MN have its IP address
as the care-of-address. When the HA tunnels the hostile FA the packets
destined to the MN, it can simply drop them or foward them to another host.
Thus, it is important to authenticate the FA's identity.

It is optimal that MN-FA directly authenticate each other. However, it is
very likely
that they don't share a security association in advance. As we mentioned
before,
one way is to let the home domain server (e.g. AAAH) generate a session key
and deliver it through a secure way to MN and FA. This method would
introduce
significant overhead due to key generation, encryption and decryption (AAAH
first encrypt it
with the security association it shares with AAAF. Then AAAF decrypt it and
encrypt
it with the security association it shares with FA). The other method is
to use asymmetric authentication between MN and FA. However, it could
also introduce significant overhead especially to the MN due to the
intensive computation
load of asymmetric crypto-algorithm and the delay resulting from certificate
verification.
In a wireless network, the MN has the need for power-saving. The less and
shorter the
signaling message it has to transfer and computation load it has to suffer,
the better.

Therefore, we try to circumvent this direct authentication by skpping the
direct authentication
between MN and FA. But implicitly deduce it from the success of MN-HA and
HA-FA two-way
authentication. Please refer to my previous email for detail.

>space than IP addresses may be useful. But perhaps this is beyond
Yes, I think the identifier should based on person, but not device.
NAI is the trend, I think.

>wireless channel) to the MN.
It's not an exception. With your method, the key still has to be deliver
securely to the FA.

>significant.
This is not that simple. Although there is an HA->FA flow, there may
not be a HA-FA security association. The overhead comes from encrypting
and decrypting the session key.

>In general, asymmetric key based systems can
Could you please give an example?
Anyway, the on-line authorization should be done by the specific access
network.
MIP is a module above it.

In addition,I agree that in a hierarchical structure, when the FA/HA is a
part
of the access network, the FA can do surrogate registration on behalf of the

MN as long as the MN has successfully registered to the access network.

>key).
I think you are talking about using random number with challenge/response
for replay protection, right?

Regards,
Gao Qing

---

From: "Lipford, Mark" <[email-masked]>
Date: Mon, 23 Aug 1999 11:39:32 -0500

-----Original Message-----
                From:   Basavaraj Patil [mailto:[email-masked]]
                Sent:   Friday, August 13, 1999 11:58 AM
                To:     [email-masked]
                Subject:        Re: [MOBILE-IP] routing optimization
authentication

                >>>>> I certainly cannot dispute the fact that a full blown
PKI has scaling
                >>>>advantages,
                the
                >>>Because with the current plans of CDMA deployment, it
really isn't a
                needed
                node.

                Pat,

                So the broker is a CA and issues certs to the roaming
partners? What I
                am refering to is the case where you have a few service
providers who
                agree to cross certify their CAs as a result of roaming
agreements
                between them. The PKI managed by a service provider could
issue certs
                to the mobility agents. I am not refering to brokers at all.
Well I
                guess you could still have a broker concept to minimize the
number of
                associations between roaming partners, but in a small subset
it does
                not really matter.

                In order to provide service to a foreign MN the visiting
network needs
                to be assured of receiving payment. Since the FA and HA
*may* authenticate
                each other via certs, receiving a successful registration
reply should
                be sufficient (in my opinion). What other authorization info
(in the
                present context) needs to be provided to the visiting
network in order
                to provide service. Of course you will need the capability
of
                generating accounting records and that's where the *A* of
AAA may fit
                in. Maybe I am missing your point Pat....If I am please
clarify.

                -Raj

                There seems to be a continued assumption that we are only
talking about Roaming between wireless Carriers.  That is not a problem as
far a revenue assurance.  Any roaming between Carriers will be validated and
revenue assured vai the RF technology (CDMA HLR validation).  The Roaming
that I (as a carrier) is wanting to handle is from a non-RF MIP provider.
To me this is everybody EXCEPT the wireless carrier.  Let's look at this
discussion from that view point.

                Regards