Some action items on Keith, RL Bob and me:

*** Develop a brief description of client authentication to use in the 
workplan
Bob Morgan gave us the following:

ISD = "Internet Standards document"
(I) = "recommended Internet definition"
(C) = "comment"
(D) = "non-recommended definition"

    $ authenticate
       (I) Verify (i.e., establish the truth of) an identity claimed by
       or for a system entity. (See: authentication.)

       (D) In general English usage, this term usually means "to prove
       genuine" (e.g., an art expert authenticates a Michelangelo
       painting). But the recommended definition carries a much narrower
       meaning. For example, to be precise, an ISD SHOULD NOT say "the
       host authenticates each received datagram". Instead, the ISD
       SHOULD say "the host authenticates the origin of each received
       datagram". In most cases, we also can say "and verifies the
       datagram's integrity", because that is usually implied. (See:
       ("relationship between data integrity service and authentication
       services" under) data integrity service.)

       (D) ISDs SHOULD NOT talk about authenticating a digital signature
       or digital certificate. Instead, we "sign" and then "verify"
       digital signatures, and we "issue" and then "validate" digital
       certificates. (See: validate vs. verify.)

    $ authentication
       (I) The process of verifying an identity claimed by or for a
       system entity. (See: authenticate, authentication exchange,
       authentication information, credential, data origin
       authentication, peer entity authentication.)

       (C) An authentication process consists of two steps:

       1. Identification step: Presenting an identifier to the security
          system. (Identifiers should be assigned carefully, because
          authenticated identities are the basis for other security
          services, such as access control service.)

       2. Verification step: Presenting or generating authentication
          information that corroborates the binding between the entity
          and the identifier. (See: verification.)

*** Write up a short blurb about what we mean about client authentication.
My recollection of our discussion in UNC is described by the following from
RL Bob in a discussion between KH, RM and MG.

(a) the user could use webiso and get a webiso-style authentication token,
as a cookie, for the gatekeeper.  An H.323 client could somehow get access
to this token (I guess on Windows non-IE apps can get access to the IE
cookie store) and present it to the gatekeeper in the H.235 authentication
step.  Might work, but would be IE-only, maybe Windows-only.  User would
have to know to go to weblogin before initiating connection.

(b) the H.323 client could be extended to do some HTTP also, and interact
with weblogin as though it were a browser, get the authn token, use it to
authenticate to gatekeeper H.235-style.  Not too bad, though requires
big-time H.323 client changes.

(c) the H.323 client could be Kerberized and the H.235 exchange could be
made to use Kerberos.  This isn't webiso, though.

(d) via KX509 or perhaps even via webiso, or even SACRED, a client could
get a X.509 private key.  This will work with H.235 as defined, though
probably would require new H.323 clients that support.  This is most
mainstream but requires a certain amount of cert handling in the client.

and (b) is what was given strongest consideration at the UNC meeting.
option (d) is probably the long term solution, but, given that PKI is not
widely deployed on campuses, (b) is more attractive for the short-haul.

*** Regarding the understand of H.235 Annex D

Bob and I came to the same conclusion... a lot of TLS stuff but 
understanding
of H.225 and H.245 is needed to really know this stuff.  We probably need to
have a discussion with some expert in Annex D to see if option (b) is 
doable.

I hope this addesses a few of our action items.

/mrg