Subject: comments on the requirements I-D

From: Alper Yegin <[email-masked]>
Date: Wed, 04 Jun 2003 15:35:22 -0700

These are Francis Dupont's comments on the PANA requirements draft.
Thanks Francis!

Alper

------ Forwarded Message
From: Francis Dupont <[email-masked]>
Date: Tue, 03 Jun 2003 15:57:35 +0200
To: Alper Yegin <[email-masked]>
Cc: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Subject: Re: last call

In draft-ietf-pana-requirements-06.txt:
 - 3. Terminology (possible spelling error)
        link-layer address, switch port number, etc. of a connected
                                                   ^ comma?

 - same (wording)
        The entity whose responsibility is to authenticate the
        credentials provided by a PANA client and grant network

 => the object of the authentication is not the credentials,
    I propose something like "verify" in place of "authenticate"
    but this is an English terminology pb (so ask a native :-).
    See 4.1.1 intro too.

 - 4.1.1. Authentication of Client (wording)
   authenticating the PaC is not sufficient. Mutual authentication
   capability is necessary in some environments but not in all of them.

 => s/necessary/required/ ?
 I have a little concern about the wording, to summary (from 802.1aa D5):
 "It should also be noted that from the point of view of security, two
  one-way authentication exchanges in each direction are not equivalent
  to a single mutual authentication exchange, since the two one-way
  authentication exchanges are not cryptographically bound together."
 So I propose to change:
   Both the PaC and the PAA MUST be able to authenticate each other for
 into something like
   Both the PaC and the PAA MUST be able to perform a mutual authentication
for

 - 4.1.2. Authorization, Accounting and Access Control (Microsoft bug)
   verify the authorization of a PaC so that PaC’s device may send and
                                                ^ use a '

 - idem (question)
   check why RADIUS and Diameter use different cases (IMHO the reason is
   that RADIUS is an abbrev and Diameter a full name).

 - 4.1.4. Identifiers (wording)
   PaCI (e.g., username, NAI, FQDN, etc.). This requirement generally

   => if (and only if :-) someone complains about jargon usage, replace
   FQDN by something else (like DNS name).

 - 4.2. IP Address Assignment (wording)
   address before using this protocol. Allocating an IP address to
   unauthenticated PaCs may create security vulnerabilities, such as IP

   => either "IP addresses" or "an unauthenticated PaC" (IMHO
   all plural is the best as the issue involves repetition).

 - 4.4. PAA-to-EP Protocol (wording)
   PAA to EP. Depending on the PANA protocol design, support for either
   of the pull model (i.e., EP initiating the PAA-to-EP protocol
   ^^
   exchange per PaC) or the push model (i.e., PAA initiating the

 - same (same)
   same

   => IMHO "either" introduces an "exclusive or" so I dislike the final
   "or both". (again, ask a native :-)

 - same (possible spelling error)
   end of a successful PANA exchange without the EP ever sending a
                                                    ^^^^ even?

 - 4.6. Interaction with Other Protocols (wording)
   be able to co-exist and not interfere with various mobility
                              ^ add "badly" here

   => rationale: good interferences should be allowed.

 - same (same)
   [DHCP]. It MUST NOT make any assumptions on the protocols or

   => add DHCPV6, i.e., s/[DHCP]/[DHCP,DHCPV6]/

 - 5. Security Considerations (wording)
 => please add here a reference to [SECTHREAT]!

 - 8.2. Informative References (refs)
 => please update the 8021X reference (the IEEE standard is no more
 a draft!)

 - same (same)
 => please add a reference for [DHCPV6]

Thanks

[email-masked]

------ End of Forwarded Message