Subject: Re: [MOBILE-IP] Latest Challenge draft issued

From: Patrice Calhoun <[email-masked]>
Date: Thu, 21 Oct 1999 18:56:40 -0700

>Pat,
>
>
>Thanks for your reply. My comments below (RADIUS discussion at the end).
>
>
>> exception. There really hasn't been any talk of backward compatibility in
>> this draft, and I do not think that Charlie and I wanted to open up
>> that
>
>
>I am not sure what you mean by " hasn't been any talk of backward
>comaptility in this draft". Are you saying that all the mobiles have
>to support Challenge-Responce? and the FAs that supports those old
>mobiles as well as the new ones cannot be complient with this draft/RFC?

No. Simply that if a Foreign Agent wants to let a mobile that doesn't include
the challenge, then it is a local policy decision. Clearly, as per the draft,
you don't want people getting around the challenge/response by requiring that
the FA simply let them through with the assumption that they do not support
the challenge/response draft.

An analogy would be in the IP Security world that 40bit DES is no longer
supported, and clearly a Security Gateway shouldn't HAVE to let them
in just because a client states that's all it can do. If the security
gateway has a policy to let the client through, then so be it.

Again, this is not a standards issue, but rather an implementation issue.

>
>
>> door. Some of the rules in the draft state that the mobile MUST include
>> the challenge and the response, but an old mobile would not recognize those
>> and, of course, it wouldn't add them to the registration request. If a
>foreign
>> agent is configured to allow access even without the challenge, then I
>believe
>> it is a local policy issue, and not one that we need to address in this
>> draft. First off, how would a foreign agent know that it is dealing with an
>> old mobile as opposed to a new mobile that is trying to get around the
>> new authentication scheme?
>
>
>It is strange that we are approching the problem from the other way
>around.
>
>A  foregin agent  can be  configured to make  a  new feature mandatory
>(e.g., reverse tunnenling  or chanllenge response)  but  not the other
>way around. And if configured to make something mandatory and does not
>have  the required  information  in the  registration message  then FA
>should indicate  to the mobile  of it (eg.    saying that a pirticular
>feature  is  mandatory  and    the  mobile   did  not    include  this
>information).  This way  backward  compatibility   and flexibility  is
>acheived to some extent.

So what good does it do to tell a client that an extension it doesn't
even recognize is mandatory? Certaintly the mobile node won't adapt
around the problem. In any case, there is an error code specified in
the draft if the expected challenge is absent. Again, if a mobile doesn't
understand that error code, it also won't know what to do with it.

>
>Also, in the future if we want to have a different authentication
>mechanisim by having another extension to the the Router Discovery
>qProtocol, the above method will make it easy (accoriding to the
>current wording it may be hard to make them co-exist with the FA
>challenge).

How so? Authentication, or security, extensions are difficult to
simply allow for backward compatibilty, since the security feature
was probably added in order for the protocol to be MORE secure. You
don't want people getting into a bidding down war to the lowest
authentication scheme possible.

>
>
>
>
>
>
>> >
>> >Why should this be sent to the Home Agent and not to the verification
>> >infrastructure.
>>
>> Because the ROAMOPS WG has deemed RADIUS inappropriate for roaming
>enviromnents.
>> Why should we, the Mobile IP WG, state that it is ok to make use of
>> RADIUS?
>
>To   my knowledge  only  protocol  RFC2607    talks  about  in roaming
>envoirnments is RADIUS.  The problems are   also very bussniess  model
>dependent.

Yes, RFC2607 describes roaming using RADIUS, and section 7 specifically
talks about its weaknesses. RFC 2477 was put together with the intent to
start evaluating new protocols against the requirements.

If you like, please take this up on the roamops list, not here.

>
>
>
>> Note that I was talked down to a SHOULD from a MUST, so if you want to run
>> RADIUS in a roaming environment, then the draft DOES allow it.
>
>
>RADIUS is being used in Proxy environemnts currently. For roaming and
>wholesale dial.
>
>Please see
>http://www.ietf.org/internet-drafts/draft-ietf-radius-radius-v2-01.tx
>which is clarifications to RFC2138 for use of RADIUS in Proxy
>environments.

Sorry, but the list of changes to the protocol DO NOT meet RFC 2477
requirements. Please take this up on the lists where people are active
in this space as opposed to Mobile-IP. A good one, again, is roamops.

>
>I don't see why Mobile IP WG should limit the use of RADIUS.

I'd like to understand better your insistence on using RADIUS to address
this problem when a working group has deemed that it is insufficient, and
a new WG has been setup to address the problem.

PatC

PS: Why do I feel I'm at a 3gpp meeting? :)

---

From: Pete McCann <[email-masked]>
Date: Fri, 22 Oct 1999 10:15:10 -0500

Pat, Gopal,

>> I don't see why Mobile IP WG should limit the use of RADIUS.

PC> I'd like to understand better your insistence on using RADIUS to address
PC> this problem when a working group has deemed that it is insufficient, and
PC> a new WG has been setup to address the problem.

I think everyone understands that RADIUS is not a good long term solution
to the roaming problem when there are mutually untrustworthy parties in
a roaming consortium.  However, in the short term, and for situations
where there is a greater degree of trust among the parties (maybe even
the single-domain case!) RADIUS may be all we have to work with.  I don't
see why the Challenge-Response draft should prohibit the FA from using
whatever mechanism it has available to verify the challenge-response to
its satisfaction.

Note that this could apply to a non-roaming case: both the MN and FA
belong to the same administrative domain, but the administrator
decided it was easier to configure a Challenge-Response secret than a
MN-FA secret, so that clean support for both non-Mobile IP PPP CHAP
and Mobile-IP FAC clients could be provided.  RADIUS is perfectly
acceptable for this environment.  For these reasons, I think the draft
should just specify the MN-FA interface (such as authentication
algorithms) and then get out of the way when it comes to back-end
processing.

PC> PatC

PC> PS: Why do I feel I'm at a 3gpp meeting? :)

:) Maybe because 3GPP2 is the main customer for this draft...

-Pete

---

From: Dave McNamee <[email-masked]>
Date: Fri, 22 Oct 1999 08:25:46 -0700

Pat-

I dont completely agree with some of the statements you make here at the
end, so:

<snip>

> >> Why should we, the Mobile IP WG, state that it is ok to make use of

Ill review the discussion in ROAMOPS again, but I dont remember this
being in their last charter. They were developing the drafts for the phone
book, and requesting AAA determine a protocol, and then they were
"disbanded" by the IESG.

In fact, we have a RADIUS server that runs very well in proxy environments,
and is doing so in several major ISP networks, especially in the area of
wholesale dial. Performance and reliability are not even an issue with this
implementation. RADIUS tends to leave a lot to the implementation: 1) that
is not necessarily bad, it leaves the vendors room to meet their customers
needs, and 2) that can be corrected via new standards.

As for the other question, neither ROAMOPS or Mobile IP should
care, at this point, what the exact protocol is. Requirements need to
be made, and discussed on their individual merits. In the end, the AAA
list will have a comprehensive list of AAA requirements for a new
protocol. (Which I believe they have just announced - great job all).

At that point, drafts can be submitted (RADIUS v2, DIAMETER,
or something else), and the AAA team can determine the appropriate
standard based on all of the AAA requirements. It seems unfair to drive
the requirements discussion towards your bias (DIAMETER) or mine
(RADIUS).

The discussion should center on requirements - irregardless of
an existing protocol. If we want to add current installation needs,
it would have to include RADIUS, as not enough major vendors
are supporting (or have been given the business case - customer
req for) DIAMETER. Yes there may be limitations, but the business world
will not wait for a brand new protocol, they will start with some base
line. (I know this is covered in the backwards compatibility req's).

> a new WG has been setup to address the problem.

It is a bit silly to say this discussion should be brought up in the ROAMOPS
list, as they have no charter to discuss this issue currently (or any other,
now
that they are done). Additionally, some of the questions come up based on
the roaming/proxy possibilities in a Mobile-IP or wireless environment.

The frustration, as I have watched some of the discussion, is being told
DIAMETER is the answer, when not all of the questions have been asked.
As I said, we should come up with requirements based on individual merit,
not what we want final implementations to be (pointing fingers at all biases
equally).

-d

Dave McNamee
Cisco Systems, Inc

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 23 Oct 1999 11:03:27 -0700

Since a recent thread has referred to the AAA WG, I thought
I'd pop my head in, and say a few words about how we see
AAA WG and Mobile IP WG working together.

We see the role of the AAA WG as the supplier of technology
to meet the needs of other WGs and standards bodies. In
order to be a good supplier, we need to make sure that we
understand the needs of our customers, one of which is
the Mobile IP WG.

From our perspective, the Mobile IP WG owns specification
of their AAA architecture and requirements. For this
reason, we have asked that draft-ietf-mobileip-aaa-reqs-00.txt
be discussed in the Mobile IP WG, where there is the
biggest concentration of Mobile IP-knowledgeable individuals.
This ensures that the AAA WG will receive requirements
that have consensus within the Mobile IP community. This
is critical to ensure that the AAA WG delivers a protocol
that meets the needs of the Mobile IP community.

If and when the AAA WG receives submissions that relate to
the architecture or requirements of Mobile IP we will request
that they be referred to the Mobile IP WG. This ensures that
the AAA WG will not become a forum for doing an end-run
around the consensus of other WGs. Similarly, we request
that other WGs refer issues of AAA protocol design to us.

Now that we have got our first requirements summary document
out, it is expected that we will have a lively discussion in
DC relating to those requirements. We have requested that
members of the Mobile IP and TIA 45.6 communities present at
the AAA WG sessions, an agenda for which is enclosed below.
We invite members of the Mobile IP community interested in
AAA issues to attend the discussion.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Bernard Aboba
Sent: Saturday, October 23, 1999 12:15 AM
To: [email-masked]
Cc: 'Paul Krumviede'
Subject: Preliminary DC Agenda

Here's a preliminary agenda for DC. If you'd like to
get on the agenda (or if you're listed, but can't attend),
let us know.

Wednesday morning (9:00 - 11:30)

Network access AAA requirements: (90 minutes)

Mark Beadles, draft-ietf-nasreq-criteria-03.txt (20 minutes)
Tom Hiller, draft-hiller-cdma2000-aaa-00.txt (20 minutes)
Charlie Perkins?, draft-ietf-mobileip-aaa-reqs-00.txt (20 minutes)
Panel, draft-ietf-aaa-na-reqts-01.txt (30 minutes)

Note that we will first discuss the individual contributions making
up the requirements matrix, and then at the end will have time
for questions relating to the summary document and the
relationship between requirements in different areas.

Accounting drafts: (60 minutes)

Bernard Aboba, draft-aboba-acct-02.txt (20 minutes)
Accounting records and attributes: (20 minutes)
A. Blount, draft-blount-acct-service-00.txt
N. Brownlee, draft-brownlee-accounting-attributes-00.txt
Jari Arkko, draft-arkko-acctreq-00.txt (20 minutes)

Thursday afternoon (13:00 - 15:00)

Authorization sub-group drafts:

draft-ietf-aaa-authz-arch-00.txt
draft-ietf-aaa-authorization-reqs-01.txt
draft-ietf-aaa-authz-samp-00.txt
draft-delaat-aaa-generic-00.txt

Since we've got an awful lot to go through in our two days
of face to face meetings in DC, to get through
all of it, we would like to emphasize that people
need to read the drafts beforehand. Presenters can
assume that the audience has read the material so that
there is no need to rehash everything. Emphasizing
key issues is fine.