> CAT-WG meeting minutes, Orlando IETF, 7 December 1998, reported by John > Linn > (RSA Laboratories). > > GENERAL DISCUSSION > > The CAT WG met for one session at the Orlando IETF, with approximately 80 > attendees. IESG activities on submitted WG documents were reviewed briefly > (SNEGO to Proposed, IDUP to Informational), and an action as proposed and > discussed on the mailing list to resolve a recently-detected GSSV2 > misalignment in advance of IESG submission was presented without > objection. > > > KERBEROS PKINIT/PKCROSS WG LAST-CALL DISCUSSION > > Significant discussion, led at the meeting by Brian Tung (ISI), took place > in response to the recent PKINIT/PKCROSS WG Last-Call. It was accepted > that > consideration of PKCROSS advancement is to be deferred pending resolution > of > an issue (also involving Kerberos-Revisions) on usage of ticket > extensions. > > At the meeting, significant sentiment was indicated that CMS constructs be > included in PKINIT by reference rather than by value, to ensure continuing > alignment between WGs' activities and usability by PKINIT of S/MIME > toolkit > code. An argument was made, however, that existing PKINIT code would > motivate keeping PKINIT as currently written. PKINIT uses CMS' > EnvelopedData > construct, which has changed in the CMS specification relative to PKCS#7 > V. > 1.5. Ted Ts'o (MIT) pointed out that a normative reference to CMS would > imply the need for PKINIT to await RFC publication of CMS. Russ Housley > (Spyrus; S/MIME WG chair) anticipated that pending CMS issues would be > reconciled within the IETF meeting week and that CMS should go to IETF > Last-Call within December. Jeff Schiller (MIT; security co-AD) suggested > that PKINIT's CMS citations be changed to "by-reference", with subsequent > recourse to "by-value" only if needed. > > Marc Horowitz (Stonecast) raised additional PKINIT issues: he considered > it > desirable to be able to use Diffie-Hellman without PKI, and to support > public keys for application servers. It was suggested that these be > considered in separate drafts. Ted Ts'o proposed that they could comprise > additional PKINIT modes, and Marc stated that he may pursue a > Diffie-Hellman > proposal. Cliff Neuman (ISI) recommended that the PKINIT specification > should emphasize PKINIT's widely implemented modes, with other modes and > new > proposals to be placed in separate specifications; he observed, e.g., that > a > subset of PKINIT modes are implemented by Microsoft and CyberSafe. > > PKINIT discussion reached the following working conclusions. PKINIT is to > be > restructured, with the digital signature and private key storage > facilities > to be placed into separate drafts. Current "by-value" references to CMS > constructs will be replaced with references to the CMS draft. The > "by-value" > references will be restored only if dictated by CMS' advancement schedule; > it is planned that a final determination will be made no later than the > March 1999 IETF meeting. > > GAA AND XGSS > > A comparative presentation surveyed the relationship between GAA and XGSS > documents; approximately 15 attendees indicated interest in progressing > authorization activities within the CAT WG, with no opposition indicated, > and a GAA document revision is planned. > > Denis Pinkas (Bull) presented a comparison between the approaches in the > GAA > (draft-ietf-cat-acc-cntrl-frmw-01.txt) and XGSS > (draft-ietf-cat-xgssapi-acc-cntrl-03.txt) drafts. The ISO access control > framework includes an Access Decision Function (ADF), an Access > Enforcement > Function (AEF), and Access Decision Information (ADI), which were > described > as a basis for comparison between the approaches. GAA has 2 APIs: > get_object_policy_info, providing ADI results used as inputs to > check_authorization, which performs ADF. XGSS has more interfaces: > get_sec_controls, get_sec_attributes, get_received_creds, > set_cred_attributes, set_cred_controls, and compound_creds. Conclusion: > GAA > and XGSS are complementary. An application can call for an authorization > check using gaa_check_authorization or can use get_sec_attributes as the > basis to perform its own authorization checking. In both approaches, one > could consistently use get_sec_controls, set_cred_attributes, > set_cred_controls, and compound_creds. Denis observed that both > approaches > solve portions of the overall authorization problem, noting as an example > that a GAA target must manage associated authorization data, typically in > a > mechanism-dependent way. > > Cliff Neuman presented additional GAA material. The main GAA change > relative to the previous version is that get_object_policy_info is now > less > ACL-specific. Cliff agrees that GAA and XGSS are complementary, but > (consistent with Denis' comments) notes that they don't span the whole > authorization space. GAA was intended to fit the model of an existing > context, against which target-maintained authorization data is applied. > GAA > recognizes a target's need to manage policy, but its scope doesn't extend > to > management interfaces. Relative to GAA, XGSS offers richer functionality > in > credential management and modulation. > > Two GAA questions raised on the mailing list were revisited at the > meeting: > level of portability offered, and support for POSIX/NT ACLs. A question > had > been raised on the mailing list as to how much portability is afforded by > GAA, given application-specific policies which must be coordinated by > generators of credentials. GAA developers have been working with the > internet printing protocol as a candidate example user. Cliff Neuman > believes that POSIX/NT ACLs should be supportable within GAA, but Denis > questioned their suitability to a distributed environment. > > A question was raised about the relationship between GAA/XGSS and the AAA > work discussed in a separate BOF. It was clear that GAA and XGSS specify > services and interfaces, while AAA is emphasizing protocol issues, but the > underlying assumed model(s) may differ. Also, the current AAA work > appears > to be more specific to a particular application. Jeff Schiller stated > that > he may request liaisons between CAT authorization activities and other WGs > such as AAA and LDAP. > > Ongoing revisions are planned to GAA. Only minor changes, if any, are > currently anticipated to XGSS. GAA has an available prototype > implementation. XGSS has an implementation over SESAME as of mid-1998, > but > this implementation is not publicly available. Ted Ts'o noted that it > would > be useful to see multiple implementations of either or both GAA and XGSS > to > validate the approaches' portability beyond an initial mechanism. > > KERBEROS-REVISIONS AND OTHER KERBEROS-RELATED DOCUMENTS > > An update to the Kerberos-Revisions draft is planned by mid-January, > identifying deltas relative to RFC-1510 and also addressing outstanding > discussion re inclusion of new fields, ticket extensions, and ASN.1 > encoding. Outstanding comments are to be addressed, assigned values for > encryption types are to be fixed, and triple-DES specification is to be > incorporated. An update to krb5gss-mech2 is planned, once issues including > name types are discussed on the WG mailing list. Revision and > implementation > work are also planned on the Kerberos-Passwords draft. > > Ken Hornstein (NRL) presented discussion on the Integrating Single-use > Authentication Mechanisms with Kerberos document. A currently-outstanding > issue concerns the key which is to be used in checksum construction. Ken > wants to do a test implementation before proceeding further with the > document, and also to do general style/grammar cleanup. He hopes that the > result will be ready to move forward by the next IETF meeting. > > Jonathan Trostle (cisco) led discussion on the Extension to Kerberos for > Additional Initial Encryption (kerberos-extra-tgt) draft. Comments from WG > members re possible progression of this draft within the CAT WG are > solicited to the list. As stated, its goal is to strengthen the initial > exchange between user and KDC, preventing brute force attacks against > passwords. The approach employs keys from a host-level TGT, mixed using > HMAC/SHA with a user key, to carry an encrypted session key. It was noted > that the approach is dependent on a trustworthy host-level secret, so may > be > less applicable to shared workstation configurations. A possible > alternative > strategy using Diffie-Hellman rather than a host-level Kerberos key could > be > considered, but would be slower. It was also suggested that use of this > approach may be appropriately configured on a per-user rather than a > per-host basis. No identified implementation plans were apparent for the > facility; it was noted, however, that Mike Swift co-authored the draft at > Microsoft and that interest may exist there. It was also observed that a > similar facility was specified within a DCE RFC and implemented in a > product > base, approximately four years ago. > > Jonathan Trostle led another discussion, on the Public Key for KDC > Recovery > draft. Comments from WG members re possible progression of this draft > within > the CAT WG are solicited to the list. Three potential approaches were > suggested to support recovery from KDC compromise: (1) use PKINIT > universally, (2) use the approach described in the pk-recovery-01 draft, > or > (3, simpler than (2)) modify the draft to perform PKINIT and specify > password change processing. As simplifying assumptions, it can be assumed > that all public keys are certified within a PKI and/or that all users are > registered with public keys. Brian Tung argued that since recovery > operations are rare, the fact that (3) incurs 2 extra round-trips and that > users must change passwords doesn't represent a significant burden, and > therefore prefers (3) in the interests of simplicity. > > PGP-TICKET > > A PGP Ticket draft was presented to inform the WG and to solicit possible > interest on its advancement within CAT as an authorization mechanism. > Comments from WG members re possible progression of this draft within the > CAT WG are solicited to the list. > > Tony Mione (Rutgers) gave a brief presentation on the PGP Ticket I-D, > draft-moscaritalo-mione-pgpticket-01.txt. It is being discussed on the > ietf-pgpticket@vmeng.com mailing list; subscription requests can be made > to > requests@vmeng.com with a Subject field containing "subscribe > ietf-pgpticket". PGP Ticket is an authorization mechanism based on Open > PGP > V4 Standalone Signature Packets. It uses a challenge-response mechanism > to > ascertain identities, and has some similarities to SPKI certificates. > Ticket structure includes predefined subpackets (certificate starting > validity, expiration, and issuer), notation subpackets (where "AUTH" > describes allowed access types and "SUBJ" identifies the subject's public > key), a hash check value, and a signature. > > A typical PGP Ticket scenario was described as follows: a user approaches > a > service administrator for access to a service, the administrator creates a > ticket with requested attributes, and the user gains server access by > presenting the ticket and responding successfully to a challenge. Client > and server systems integrate PGP Ticket processing functions. Tony > commented that the proposal may be changed to avoid leaking information > about access attempts, and that PGP Ticket could be used for GAA/GSS, FTP, > or other prospects. In discussion, it was also suggested that it might > be > used for calsched and other ACL-consuming applications. It was noted that > a > PGP ticket may be usable as a capability; it was also noted that ticket > revocation is not currently provided and that the issue needs to be > considered. > >