NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Chair(s):
C. Newman <chris.newman@innosoft.com>
Matt Wall <wall+@andrew.cmu.edu>
Applications Area Director(s):
Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Applications Area Advisor:
Keith Moore <moore+iesg@cs.utk.edu>
Mailing Lists:
General Discussion: ietf-acap+@andrew.cmu.edu
To Subscribe: ietf-acap-request+@andrew.cmu.edu
Archive: anonymous IMAP: cyrus.andrew.cmu.edu:archive.ietf-acap
Description of Working Group:
The goal of this working group is to define, specify, and develop the Application Configuration Access Protocol as a general access mechanism for per-user and per-server structured lists of information. In addition, the Working Group will specify how to use the protocol to store specific structured lists, initially application configuration options and addressbooks.
The Application Configuration Access Protocol is a proposed solution to the problems of client configuration for users of the internet.
Given the increasing prevalence of network access points and rapidly increasing numbers of users with diverse needs and settings, there is a phenomenon of internet application users who typically connect from more than one physical location and/or operating system to use the same set of internet services and applications. These users must recreate sets of personal configuration information for each system, session, and location that they use. This may include information such as application options and preferences; personal or shared user data such as addressbooks, bookmarks, or subscription lists; or shared data for internal client use, such as authorization group lists.
The products of this working group will be:
· A formal specification for the protocol
· Formal specifications of datasets used by the protocol and related extensions to the protocol
· An RFC intended to move to a Standard in a timely manner
· A specification for extensibility of the protocol in the form of a framework document
· Additional informational and/or experimental RFCs as necessary to amplify and/or extend ACAP.
Note on goals and milestones: because the work of the ACAP WG is based on the previous work done on IMSP, there is justification for a somewhat more aggressive schedule than is customary.
Goals and Milestones:
Done |
|
Submission of 'ACAP vs. Other Protocols' as Internet Draft |
Done |
|
Second internet-draft of ACAP protocol specification |
Done |
|
Submission of revised proposed WG charter to area directors |
Done |
|
Submission of 'ACAP vs. Other Protocols' Informational Document for discussion |
Done |
|
working group meeting at San Jose IETF |
Done |
|
Working implementations of client and server library |
Done |
|
Additional dataset specifications defined as directed by WG. |
Apr 97 |
|
Final internet-draft of ACAP protocol submitted to IESG for consideration as Proposed Standard |
Apr 97 |
|
Final Internet-Draft of ACAP Protocol. |
May 97 |
|
Address book dataset class submitted to IESG for consideration as a Proposed Standard. |
Aug 97 |
|
Meet at Munich IETF. Discussion to include language-based orderings. |
Sep 97 |
|
Submit remaining dataset class definitions I-D to IESG for consideration as a Proposed Standard. |
Sep 97 |
|
Conclude WG. |
Internet-Drafts:
· ACAP -- Application Configuration Access Protocol
· ACAP TYPE Extension
· ACAP Datatyping and Datatyping Discovery
· Multi-Lingual String Format (MLSF)
· Two Alternative Proposals for Language Tagging in ACAP
· Anonymous SASL Mechanism
· ACAP Authorization Identifier Datasets
· ACAP Personal Addressbook Dataset Class
· ACAP personal options dataset class
No Request For Comments
Minutes of the ACAP Working Group
Reported by: Randall Gellens
Chris presented agenda and called for comments. No comments on agenda.
Comment: post "why ACAP" doc to LDAP [?] list
I. Security Issues
Adopt SASL anonymous mechanism? Consensus: Yes (a few people liked it, no one objected).
Issue: not permitted to have plaintext login. Not possible to use ACAP without (a) upgrading one's security infrastructure or (b) violating IESG rules.
Options:
1) Require CRAM-MD5 [Discussion of pros and cons].
2) Write RFC for and require CRAM-SHA1 [Discussion of pros and cons].
3) Adopt and require SCRAM (salted verifier + encrypted hash of pw) [Discussion of pros and cons].
4) Wait for SSH or TLS and require its use (with plaintext passwords encrypted underneath) [Discussion
of pros and cons].
Comments: AARG list had other mechanism suggestions.
Answer: We want to stick with simple mechanisms to avoid delay.
Call for consensus on (4): no one liked it.
Comment: difficulty of getting implementors to adopt mechanism.
Comment: we are discussing mandatory mechanisms, SASL allows more secure mechanisms as well.
Comment: go with MUST for CRAM-xxx, SHOULD do something stronger.
Comment: go with CRAM-MD5 because it is easiest to get through standards process.
Comment: unable to get CRAM-xxx except CRAM-MD5 through Security Area
Comment: SCRAM not had review...eliminate?
[discussion of Authentication exchange and verifier both on wire; risks]
[discussion of risks of stealing host's password file]
Comment: CRAM-MD5 and -SHA1 both riskier than /etc/pw since stealing verifier gives access to all accounts
Comment: took six months to get CRAM-MD5 through standard process; new protocols take time, especially security protocols
Comment: other problems with CRAM. No authentication id. Mutual authentication problem.
Comment: go with CRAM-MD5 as baseline.
Comment: SCRAM-SHA1 needs review by crypto people. Then move forward or drop.
Call for consensus: use CRAM-MD5 as baseline; also pursue SCRAM-SHA1.
Comment: Also pursue other AARG proposals. If CRAM-MD5 is baseline, other mechanisms are optional and can be pursued in their own time
Comment: CRAM is like APOP: why not just use APOP?
Answer: APOP is worse than CRAM. More security risks. Must store password in clear on server.
Answer: CRAM-MD5 is in all ways better than APOP.
Back to consensus. No objections. CRAM-MD5 to be used as baseline; also pursue
SCRAM-SHA1.
Comment: CRAM-MD5 is the only option that is already an RFC. Harald: This is the right choice for the ACAP group. It is not for the ACAP group to do crypto protocols.
Chris Newman: ACAP has dependencies on SASL-PLAIN for transition mechanism. Since plain may not be approved, we need to remove dependencies.
Should we remove the transition error codes? That means all users must change their password to use ACAP. Should we try and get SASL-PLAIN on the standards-track? That would delay ACAP.
John Myers proposed that we leave the transition error codes in but remove the dependencies on SASL-PLAIN. That way there is a means to do transition but the mechanism is not specified.
Call for consensus on John's proposal. No objections: ACAP to leave transition error codes in, but delete dependencies on SASL-PLAIN.
Comment: How would a user get the transition error codes? No login mechanism specified in ACAP that uses them.
Answer: Through an unspecified mechanism. Maybe CRAM-MD5. The error codes mean "The server does not have auth [something] for you".
Comment: Don't we need a consistent error msg which tells users to go to their admin?
Answer: This is a UI issue.
Comment: Leave transition out of spec, do it in its own spec that updates ACAP?
Comment: Controversial proposal to transition away from plaintext?
Answer: It's not controversial.
Comment: The mechanism is controversial.
Answer: We are only leaving in the error codes, not the mechanism. Harald: I think an informational RFC that specifies a plaintext mechanism and how to use it in a transition strategy, and how to use it with IMAP login would not be any more offensive to the IESG than a document on how to do 8-bit to 7-bit downgrades in email.
Chris Newman: I intend to do that.
II. Authid/Groupid Datasets
Authid draft posted. Now in I-D directories. How many have read it? (Three people raised their hands).
Steve Hole: [summarized draft]
authentication-id, authorization-id, user-id,
authent-id -> user-id group={user-id, group-id}
Comment: Any way to associate an authentication mechanism with a specific auth. id?
Answer: Yes. Multi-value attribute which holds list of auth-ids per user-id; e.g., different Kerberos principals.
Steve Hole: Not only would ACAP use this dataset, but also other servers (e.g., IMAP) could use it.
Steve Hole: Organizations like to keep their auth-ids secret. "Hackers handbook." Also auth-ids are often meaningless (e.g., numeric).
Comment: Nothing in draft that says at any level that ID is unique.
Answer: Was supposed to be.
Answer: Must be because it is stored in the "entry" attribute, which must be unique.
Answer: Can't have auth-id bind to more than one user-id? Maybe we want to allow it.
Steve Hole: It is possible for an ACAP server to provide this dataset but not obey its semantics.
Comment: Why are there different attributes for user-ids and group-ids in group lists? Is it to allow users and groups with the same name?
Answer: It's not intended to allow that. Need to clarify.
Comment: Is there a group member-of? A way to find what groups a group is in?
Answer: Not sure how useful it is, but it should be there for completeness.
Comment: If a group is removed, it's needed to know which groups to clean up.
Comment: User name field has no semantics or constraints on it. This is a problem with interaction with other directory services. Should require minimum amount of structure? Consider one database with
ACAP and LDAP access protocols. If name is freely structured, it is very hard to impose structure later or use it from more than one place.
Chris Newman: Purpose of field is not to be a directory service; it's only to make a user-friendly UI. Make the field the LDAP common name if there is a directory service back-end.
Comment: Say that [in the spec].
Comment: Might have multiple access protocols for same data; there is a move to single storage.
Steve Hole: It's left to the discretion of the site admin to put whatever they want in there.
Comment: Sites are now trying to take old pw files and put into directory. Problem is name fields were overloaded, must be moved manually.
Steve Hole: There is a potential for other attributes. For example, expired, disabled, etc. Potentially, there are a lot. Didn't bother to specify them, but there may be a sub-set which is useful to standardize. Discuss on list?
III. Options Dataset Draft [Steve gave summary]
This was complex, but became very simple because of multi-valued attributes. The idea is it's a scribble-space for options. Certain kinds of configuration info should be shared between applications/users. Those become datasets. The draft defines rules for how such datasets are to be specified.
Also option to conventionalize single options that are useful to multiple applications, e.g., SMTP host name for mailers. Should be standardized in common, but doesn't need heavy-weight registration procedure. Need light-weight registry procedure.
Comment: What form are datasets defined in? Are datasets spec in ASN.1?
Answer: ABNF in standards-track RFC.
Comment: LDAP et al has a procedure.
Answer: That's for different problems.
Comment: Need type specified.
Answer: Other drafts are addressing that. It's not really part of ACAP. In ACAP you know what you are going after. Possible use for RegEdit-type apps (generic dataset editor) but not generally very useful.
Comment: It's not as different as you imagine from other efforts. Consider Service Location, very similar considerations. Calsched, other groups are doing similar schema work. Need to pay attention to other groups.
Comment: Service Location could be font-end for LDAP directory.
Comment: ACAP could be same thing.
Comment: Draft for how to transfer schema stuff from Server Location to others.
IV. Personal Addressbook Specification [Summary of draft]
The draft is numbered -00 but is really later. The I-D people never published the earlier version.
Users own the information in an ACAP addressbook. It can contain the user's comments on how people are jerks or whatever. Unlike a directory, this is not generally for public consumption. The information is similar to white pages. This is based on white pages, but adds attributes appropriate for personal address books (e.g., comments).
1. Issue with vCard. vCard is going to be a big deal. There is a problem mapping vCard to LDAP. It will be worse with ACAP since there is no property description. For example, phone/address. personal, cellular, etc. vCard says "this is phone number for purpose x" instead of having different named attributes. How to map? One idea is to add parallel attribute for each phone number to list what it is used for. Two attributes with relation between names. Or metadata for uses of attribute.
2. vCard allows substitution of URL for value. We could have an attribute name convention for doing this. Comment: Define attribute that is URL, one type of URL is data URL. Comment: Data URL is meaningless without typing. Comment: Meaning goes with attribute. Photo attribute has data URL; you know what it is.
3. Lots of poorly-specified attributes like 'role' and 'title.' Doesn't want to add to dataset class if specification will change. Comment: Fits with ACAP.
V. Media Types Dataset
This is a perfect fit for ACAP. User-customizable site defaults.
Comment: There was a comment in another session that lots of mail applications are broken because they don't allow selection of helper applications per MIME type.
Chris Newman: How many people had read media types dataset draft? (a few)
Chris Newman: Media types carry security warning.
Comment: Risk is in interpretive contents.
Comment: It's a disservice to not have it, but having it might cause problem getting it through Security Area.
Comment: It won't introduce new security risks.
Comment: It could carry risks to new systems. Batch files, for example.
Comment: Applications start with hard-coded list; users can add to but not delete from it.
Comment: By default in Internet Explorer everything is considered dangerous. Users can say to stop warning for all types except core list.
Comment: Could have admin supply core list to prevent users from not being warned about type "foo."
Comment: Security risks are highly application specific; plaintext is a potential risk [on some displays] but don't want to see warning for every access of plaintext content.
Chris Newman: Should we flush this attribute? Or discuss on list?
Call for consensus: A few want to discuss, no one wants to punt.
VI. Language Specific Comparitors [John Myers summarized issues]
-language
-unicode decomposition
-strength (how exact is search)
+ in general 4 cases: alphanumeric / diacriticals / case / specials
Comment: Is 'special' comma or Cyrillic without diacritical?
+ ISO 1461/1462 specifies up to 7 levels of distinction
+ Java has 4 fixed levels: primary/secondary/tertiary/identical
-version/vendor
functions won't be same between implementation.
-other qualities
+dictionary/phonebook/etc.
Strawman:
language -tag; properties
For example,
fr; secondarystrength
en; phonetic; primarystrength
ACAP base comparators:
i; octet
i; numeric
i; ascii-casefold
("i" stands for "international", cross-language)
Comment: What is "i; numeric"?
Comment: Same as ASCII numeric?
Comment: Fractions.
Comment: UTF-8 numeric.
John Myers: Specified in ISO 10646.
Chris Newman: Base spec requires support for UTF-8 but not complex mapping.
Comment: Since we're talking about atoi what about UTF-8?
Comment: Kanjii numerals.
Comment: How are these collated?
Answer: code-point order.
Comment: Entire protocol is UTF-8 but these are octets. [Lots of comments on ordering versus octets which are outside the set]
Someone (Chris?): We changed the name of the "i; numeric" comparitor to "i; ascii-numeric".
Comment: New comparitors added as extension docs?
Answer: Registry thing, like MIME.
Comment: Problem with semicolon in syntax?
Comment: Could use colon or slash.
Comment: Proposal in specific order?
John Myers: Specific order is best. Truncated case.
Chris Newman: Don't want same comparitor with two names. Sort proposal by names.
Comment: How to sort?
Chris Newman: Use US ASCII sorting.
Comment: Unhappy with having server tell client which comparitors are valid in LANG response. Can't have client that detects all comparitors available.
Chris Newman: There could be 500 comparitors. Don't want to announce them all in greeting.
Comment: use a dataset?
Chris Newman: The problem with that is it's a solution specific to ACAP; need same services in IMAP, etc.
Comment: Why do you need all comparitors?
Comment: Bilingual user, doesn't want to move into one language only.
Chris Newman: LANG has list of languages in order of preference; response has all comparitors valid in all languages.
Comment: is there a way to switch back to the default? [Discussion of difference between default language = English and switching to English]
Comment: Some kind of tag to specify technical English or "default."
Comment: This seems very complicated. Why need more than store and search?
Chris Newman: Error texts and comparitor discovery.
John Myers: "English" versus "Internationalized English"
Comment: Why so complicated?
Comment: The two variations of English MAY be different.
John Myers: Can't get comparitors without selecting language.
Chris Newman: Default language is 'en'? En = any English dialect.
Comment: Don't need to discover comparitor for English?
Comment: Yes, select En.
VII. WG Milestones & Disposition
Close down Working Group after Draft or put out dataset specs, extensions, etc.?
Comment: Keep group going until ACAP is at Draft or Proposed?
Comment: Mailing list stays around after WG closes.
Comment: Do dataset classes in charter.
Comment: Add additional dataset classes to charter.
Call for consensus on having group do all discussed dataset classes. No objections.
Do media types extension?
Comment: Ask on list; lots of discussion.
Do type labeling extension?
Comment: Do Rob's only.
Naming convention and registry for language-sensitive comparitor?
Comment: Only useful if other groups need it?
John Myers: Who has the knowledge to do it?
Comment: Spin off a new group to do it. Get more experts, raise profile.
Comment: Good idea. Get people from LDAP, etc.
Comment: BOF in December on that (?) John Myers will chair.
Chris Newman: Meet in December to discuss work on dataset classes, etc.?
Comment: Yes.
Comment: Proposal to just do dataset classes for which drafts are available.
No objections.
Want options dataset to go though at same time as spec.
Chris Newman to send in charter update. New ACAP spec with short last-call on list.
Meeting adjourned.