Here are draft minutes for IETF#58 meeting of LDAPBIS. Unfornately, we failed to get these done in time for inclusion in the proceedings. LDAP Revision WG (ldapbis) Tuesday, November 11 at 1300-1400 ================================= We met for an hour on Tuesday, November 11. Bob and Kurt presided over the meeting. John McMeeking, Roland Heldberg, and Spencer Dawkins provided meeting notes (attached). No changes were made to the proposed agenda. Kurt provided a brief status of the WG. He stated, per our milestones, we should be done by now and should try hard to deliver soon. He stated his view on the order of I-D Last Call call: Protocol, Authmeth, Roadmap. He stated we should be complete the revised LDAP TS before Seoul. Jim Sermersheim then provided a summary of outstanding [Protocol] issues (presentation attached): The WG last call generated quite a number of comments. These all have been gone through. All contentious issues have been brought to the list for further discussion. At this point, WG appears to be building consensus on how these issues. Remaining work includes: distilling the current changes in revision to a "changes since RFC 2251", changes, address issues being discussed on list, and make changes to the notation style used to be consist with other WG documents. Jim noted that detailing what that "style" is would be useful. Jim stated he would have a new revision ready for WG Last Call by end of the next week. Roger Harrison then provided a summary of outstanding [AuthMeth] issues. - The group discussed "unauthenticated bind" (simple bind with DN and an empty password) semantics. A proposal was made by Chris Neuman that the I-D should be changed so that default server behavior is to reject an unauthenticated bind. Chris was asked to state his proposal to the mailing list for WG discussion. - The group discussed at length the effects of StartTLS and TLS closure on authentication state and inconsistencies in behavior: Start TLS must drop previous authentication, while TLS closure must preserve authentication. Apparently there are some applications that would like to be able to use TLS during a bind request and drop TLS immediately after the bind. Discussion points included: -- Can a server drop previous authentication and start returning "strong auth required"? -- Access control (or other policy) could require that a server be aware of protection layers in effect at time of bind as well as during current request. Distinction between bind then TLS, TLS then bind, bind with TLS then drop TLS, etc.. -- Should StartTLS, TLS cipher renegotiatation, or other change in protection/integrity layers drop authentication? -- Proposal to make this a matter of local policy The chairs requested that this discussion be taken list as there is no clear indication in the room of consensus on these issues. Roger said he would submit a new revision adding many issues by end of following week, but felt a subsequent revision would be necessary before a WG Last Call could be issued. Kurt then lead a brief discussion of our WG milestones: - [Protocol] WG LC within the month, - [AuthMeth] WG LC in another month, - [Roadmap] WG LC not until Jan '04, - [BCP64bis] update to be WG LC in same time frame as [Roadmap]. Then forward the revised LDAP TS and BCP 64bis to the AD. Interoperability reports would be due 6 months after this. Kurt noted he believed we'd be able to meet interoperability requirements to progress the revised LDAP TS to Draft Standard (after six months at Proposed) without requiring another revision. Kurt stated he would prepare a new slate of milestones. The meeting was then adjourned.
Attachment:
jim.ppt
Description: Binary data
LDAP Revision WG (ldapbis)
Tuesday, November 11 at 1300-1400
=================================
CHAIRS:
RL "Bob" Morgan <rlmorgan@washington.edu>
Kurt Zeilenga <Kurt@OpenLDAP.org>
AGENGA:
0) Preliminaries (Scribes, Agenda, WG Status) - chairs - 5m
1) draft-ietf-ldapbis-protocol outstanding issues - editor - 20m
Jim Shermerstein
- second working group last call needed, but version 18 will have all remaining comments by end of week.
2) draft-ietf-ldapbis-authmeth outstanding issues - editor - 20m
Roger Harrison (Novell)
- correcting SASL profile in previous draft
- any SASL mechanism can be used with LDAP (PLAIN, ANONYMOUS do have overlap with LDAP)
- SASL also updating their profiles in parallel (need to be synchronized)
- What happens with layers? 2222 says old layers stay in force, but SASL is discussing that the layers be deinstalled.
May be relevant with new authentications that fail, etc.
- Server information fetched prior to SASL/TLS exchange SHOULD be discarded (unless you got the information securely in some other way)
"Servers should not allow unauthenticated BINDs in their default configuration" -
server that allows unauthenticated BINDs at all should be non-compilant?
Tim Howe's book has this attribute in example code!
Ted Hardie says this would be OK, if that's the WG consensus
We'll move this out of Security Considerations (shouldn't have MUSTs in such a late part of the document)
- Mostly smoothing changes left to do - want to generalize authentication state transition table (by removing references to TLS)
- Need to add Start TLS and TLS closure considerations
What to do, if you close TLS during a session? This could be a local matter
Is "change cipher suites" the same thing? What about other security downgrades?
Is this a configuration switch?
Most TLS profiles don't allow TLS to be disassociated - they close connections instead
- Expecting to publish 09 version next week, let it sit for a few days before last call
Need SASL to converge before our last call (go engage them, if you have opinions!)
3) Next Steps / Milestones Review - chairs - 5m
- Running a little late - finish in Novemeber, modulo SASL?
- Need to update BCP 64 for IESG and then do Interoperability reports (required for Draft Standard)
4) Open Mic - floor - remaining
LDAPBIS WG Minutes Agenda Status Protocol draft - Jim Sermersheim - see submitted presentation Authmethod - Roger Harrison - see submitted presentation - discussion on "unauthenticated bind" (simple bind with DN and an empty password). Proposal that authmethod should be changed so that default server behavior is to reject an unauthenticated bind. Will take this to the mailing list. - discussion on effects of StartTLS and TLS closure on authentication state and inconsistencies in behavior -- Start TLS must drop previous authentication, while TLS closure must preserve authentication. Apparently there are some applications that would like to be able to use TLS during a bind request and drop TLS immediately after the bind. Discussion points: -- Can a server drop previous authentication and start returning "strong auth required"? -- Access control (or other policy) could require that a server be aware of protection layers in effect at time of bind as well as during current request. Distinction between bind then TLS, TLS then bind, bind with TLS then drop TLS, etc.. -- Should StartTLS, TLS cipher renogotiation, or other change in protection/integrity layers drop authentication? -- Proposal to make this a matter of local policy WG business - aiming for road-map last call in January
LDAPBIS meeting notes IETF 58, Minneapolis, USA Tuesday, November 11 @ 1300-1400 submitted by Roland Hedberg agenda bashing - no changes Kurt stated his view on the order protocol, authmeth forward and then roadmap Should be done before Soel Status: --------------------------------------------------------- Jim S (JS) on ldapbis-protocol-18 working group last call generated quite a number of comments all has been gone through all contentious been brought to the list a half dozen left to be delt with will incorporate the rest before the end of the week doesn't think there is anything contentious left. distille the changes to RFC 2251 reminaing comments on the list adhere to the group RFC style ( someone will compile a list soon) will have a new rev ready for wg last call by end of week --------------------------------------------------------- Roger Harrison (RH) on authmeth-06 changed - sasl profile removed contradictory or repreated info from SASL draft any SASL mechanism can be used with LDAP couple of loose ends remains SASL is a moving target!! RH thinks he is in a clean state When the SASL WG is finished we have to check how what they have done impacts authmeth + Server information fetched prior to SASL and TLS negotiations SHOULD be discarded. -- Allows keeping information obtained through secure mechanisms + defined anonymous and unauthenticated binds Impose considerations on server configuration. servers should not by default allow unauthenticated bind (Chris Newman). Is it possible to make it mandatory what the servers default configuration should be. Nothing prevents the WG to state that kind of musts (Ted Harding) Move some to the text keep the discussion in the concideration. + remaining stuff - general reorganization - generalize auth state transition table -- collaps many states by removing refs to TLS - additional security considerations - clarify interaction between TLS and SASL sec layers - effect of start TLS and TLS closure on auth state -- proposal: matter local to the server Can a server invalidate a association by itself ? lengthy discussion RL Bob clearly uncomfortable about this simple bind followed by startTLS is not OK startTLS and then simple bind is OK when startTLS you must keep the credentials is what is there now. Should be discussed more on the list. on closure it is now stated that it should return to anonymous. What happens when cyphersuites are changed within one connection Is all this a protocol issue or a configuration issue ?? --Have to give guidance to implementers working on comments on the list 09 next week very close to WG last call If a flurry of issues probably have to make 10 before LC. --------------------------------------------------------- MILESTONES Kurt ( we are supposed to be done ) It sounds like LC on protocol within this month authmeth LC in another month roadmap LC not until january '04 then forward the suite to AD iana considerations BCP at the same time as roadmap 6 month after that for the interop reports pretty sure we have multiple implementations which means that that shouldn't be a hinder for the next step on the standards ladder.