Subject: Re: [MOBILE-IP] AAA request

From: "n. asokan" <[email-masked]>
Date: Tue, 28 Sep 1999 16:13:35 +0300

[email-masked] (EXT Roberts Phil-QA3445) writes:
[...]
> The chair asked me whether this document represented a consensus opinion of
> the mobile-ip working group.  So I'd like some discussion about whether the
> working group thinks this draft presents sufficient requirements for AAA
> support for mobile-ip.
[...]

I made the following notes when I first read the 'mobile IP AAA
requirements' draft.  I'm posting them here in case they are relevant
for this discussion.  The main comments are below.  Other minor nits
appear in a separate message.

Regards,
- Asokan

--------------------------8<--------------------------------

I would like to propose the following additional requirements for your
consideration in the context of mobile-IP and AAA:

1. The AAA mechanism MUST NOT preclude anonymous access to services by
   a mobile node (MN).
   -> if "authorization by X" _always_ requires "authentication to X"
      then anonymous access is precluded

2. The AAA mechanism MAY support incontestable accounting (e.g., for
   the purpose of generating incontestable billing), and in any case
   MUST NOT preclude provision of incontestable billing.
   -> rationale: different domains may not trust each other; mobile
      user may not trust the foreign domain, or _any_ domain.
   -> nonrepudiable generation of charging records may not be required
      in all scenarios; but a general AAA protocol should not
      (inadvertently) prevent it.

3. The AAA server in the foreign domain SHOULD be able to perform
   additional periodic authorization of MN's access to services
   without having to involve the home domain AAA server.  In
   particular, satisfying this requirement the previous requirements
   MUST NOT be violated.

   -> this implies that the AAA protocol should provide the means for
      the foreign domain AAA server to obtain a general 'authorization
      certificate' from the home domain AAA server during the initial
      authorization of an MN. Such a certificate can be used for
      subsequent local authorizations. In the general case, this
      cannot be a standard certificate used for authentication -- it
      must have additional information, like liability and lifetime
      limits, that can be used in an authorization check. In cases
      where nonrepudiation is not required, the 'authorization
      certificate' can be a regular certificate or even a shared
      session key.

4. Various AAA clients may be involved in the provision of services to
   an MN.  The AAA mechanism SHOULD support termination of services to
   MN at the request of an AAA client (i.e., this means that on being
   notified a request to terminate service to an MN, the AAA server
   must be able to indicate to all other AAA clients involved as
   well).

- Requirement 4 was also mentioned by someone during Charlie Perkins'
  presentation in Oslo.

My feedback on draft-ietf-aaa-mobile-ip-req-00 follows.  Some of my
comments are based on the assumption that the four requirements above
are acceptable.

Primary comments
================

I have three primary comments.  They are related.

1 Throughout the document, there seems to be an assumption that
  'authorization' is based on 'authentication' followed by access
  control (perhaps this was not the intention, in which case it may be
  useful to clarify the text).  While this is the classical approach
  to authorization, it may not be the best one, especially for the
  Internet:

  -> authentication implies some identity in a mutually understandable
     namespace (authentication is verifying the claimed identity). A
     verifying entity
  -> for anonymous access, authentication is not relevant
     (authorization still is)

  It would be more general to talk about 'verification of credentials'
  as the basis for authorization.  It is a more general notion known
  as 'trust management' (See recent related work on PolicyMaker and
  KeyNote, e.g., at http://www.cis.upenn.edu/~angelos/keynote.html).
  This is not just an academic distinction because of the anonymous
  access case.  Perhaps this is a matter of clarifying the
  terminilogy.  I would suggest the following definitions:

  authentication: the act of verifying a claimed identity, in the form
  of a pre-existing label from a mutually known name space, as the
  originator of a message (message authentication) or as the end-point
  of a channel (entity authentication).

  authorization: the act of determining if a particular right, such as
  access to some resource, can be granted to the presenter of a
  particular credential.

  i.e., if you accept this, you can reword things like:
  section 1.1, para 2:
   "... provides credentials which can be verified before access to
    resources are permitted"

   "... ability for the foreign domain to verify the mobile user's
     credentials in order to be allowed access"

   several items in the list in Section 3.1 can be moved to the
   following section.  i.e., it is authorization that must
   - be scalable, support challenge/response, must not be foregable etc.

2 Why should the foreign domain <-> home domain authentication be a
  MUST? (Section 2.1.3)

  I think the essential requirement is that each domain should
  be able to authorize the MN for accessing their respective
  services. Any other authentication should be optional, at best.

  You have a nice list of services in Section 3.2.  It seems to me
  the conclusion from this list is that:

  -> the only authentication required is MN -> HA: the HA has to
  intercept packets on behalf of the MN's home address (which is a
  pre-existing name in a well-known name space); therefore it
  needs to authenticate the registration request with respect to MN's
  home address.  Note that authentication w.r.t. this label is
  essential because the label is inherent in the definition of the
  service (i.e., "intercept and forward packets intended for
  a.b.c.d").

  -> all other authorizations MAY be based on authentication, but not
  necessarily because reference to pre-existing labels is not inherent
  in the definition of the other services.

  -> in particular, I have't yet heard a convincing rationale for FA->HA
  authentication (i.e., HA verifying FA's IP address as "genuine")

3 It is necessary to separate the 'home domain' (the AAA domain that
  helps the foreign domain to authorize the mobile node) and the 'home
  network' (where the home agent resides).  They may have nothing to do
  with each other and maybe entirely different organizations
  altogether: e.g., the mobile user may use a credit card protocol to
  pay the foreign domain for access.
  -> perhaps the term 'domain' should be defined in Section 1.2

---
N. Asokan, Communication Systems Lab, Nokia Research Center, Helsinki
E-mail: [email-masked],  [email-masked] (private)
Phone:  +358 40 743 1961; PGP Key for private use at http://www.acm.org/~asokan

---

From: "n. asokan" <[email-masked]>
Date: Tue, 28 Sep 1999 16:15:59 +0300

Typos, minor comments, and other nits regarding
draft-ietf-aaa-mobile-ip-req-00.txt.

Regards,
- Asokan

-------------------------------8<---------------------

Other comments
==============

- section 2.1.3, item 7 in list
  MUST is too strong; if the authorization protocol uses nonces to
  ensure freshness and does not require (unlike mobile IP) the MN to
  retain nonces from the previous protocol run, then the protocol must
  have at least 3 flows.  It is conceivable that a foreign domain may
  not consider the ability to send authorization protocol messages as
  a 'service' and might allow them through.

  also, item 8 in section 3.1 is a verbatim repetition of item 7 in
  section 2.1.3.

- section 3.1, item 9
  Some credentials are 'n-show credentials' which can be used only a
  given number of times (including 1-show credentials).  For such
  credentials, it is harmless if an eavesdropper is able to
  reconstruct them after they have been used.

  i.e., the requirement should be '.. any intervening node MUST NOT be
  able to learn any secret information which may enable it to
  reconstruct and reuse the credentials'

typos and other nits
====================

- some 'must', 'may' etc. appear in lower case whereas they were
  probably intended to be uppercase. e.g.,
  - 'must' in item 9, section 3.1
  - 'required' in Section 3.2, page 12 should be 'MUST'
  etc. (this is not a complete list)

- section 2.1. para 1,
  s/later/latter/

- section 2.1.3, item 4 in list
  s/may-not/may not/

- section 2.2.1, para 2
  s/who's/whose/

- section 2.2.2, item 1 in list
  "Allowing .... be allowed": either drop the first "Allowing" or drop
  the last "be allowed" (and change the first word to "Allow")

  (also reproduced in section 3.4)

- section A.1.2. para 2
  s/beconning/beaconing/

---