Subject: Re: authmeth-15 notes

From: "Roger Harrison" <[email-masked]>
Date: Thu, 13 Oct 2005 10:41:23 -0600

Roger Harrison writes: 

>>>>> Hallvard B Furuseth <[email-masked]> 09/22/05 4:26 pm >>> 
>>>> Abstract 
>>> 
>>>>   This document discusses various authentication and authorization 
>>>>   states through which a connection to an LDAP server may pass and the 
>>>>   actions that trigger these state changes. 
>>> 
>>> Now that the state tables are gone, this particular info is only 
>>> available by reading the whole document, looking for state changes. 
>>> (Aha $,1rq(B finally I understand what the tables were good for:$,1rq(B) 
>> 
>> Are you thinking that we should put them back into the document?  I'm 
>> fine with doing so if there seems to be consensus that doing so would 
>> be useful. 
> 
>No, just a single sentence somewhere under Authorization State. 

I've completely reworked this section for -16. I think this should meet your request now. 

> 
>>> Anyway, maybe Section 4.something should mention that Bind is the 
>>> operation which can change authorization state, and in addition TLS 
>>> operations can invalidate the association. 
>> 
>> The first paragraph of section 4 already states that the Bind 
>> operation is used to allow the client and server to exchange 
>> information that changes the authorization state. 
> 
>Yes.  What it doesn't say is that no other operation (in the core 
>standard) does that, except for invalidating associations. 
>So I need to change assoc state has a quick answer in the document, 
>but when can assoc state get changed? requires a scan of the whole 
>document. 

I believe this is also now covered in the rewrite of the Authorization State -16. If not, please suggest some words at a specific location. 

>>>> 3.1.4. Discovery of Resultant Security Level 
>>> 
>>>>   If the client or server decides that the security level is not high 
>>>>   enough for it to continue, it SHOULD gracefully remove the TLS 
>>>>   connection immediately after the TLS negotiation has completed (see 
>>>>   [Protocol] section 4.13.3.1 and section 3.2.3 below).  The client 
>>>>   may then either close the transport connection, attempt to StartTLS 
>>>>   again, send an unbind request, or send any other LDAP request. 
>>> 
>>> The server too can close the connection.  I don't remember what's the 
>>> use of such a def what the server can do. 
>> 
>> In reviewing [Protocol] section 4.13.3.1, I believe that this is 
>> adequately covered there. I have deleted the last sentence of this 
>> paragraph. 
> 
>You seem to be reading an old [Protocol] draft.  Protocol‑31 does not 
>mention graceful TLS closure at all.  Protocol‑31 StartTLS is section 
>4.14, not 4.13. 
> 
>If I remember correctly, it was decided some time ago to move several 
>protocol‑like issues involving TLS from [protocol] to [authmeth]. 
>Don't remember why. 

In the end, we decided to keep protocol issues in [Protocol]. Section 4.14.3 of [Protocol] covers removal of TLS layers. The last paragraph explicitly allows either protocol peer to terminate the LDAP session after sending or receiving a TLS closure alert, so I believe this issue is resolved. 
>‑‑  
>Hallvard 

Thanks, 

Roger

---

From: "Roger Harrison" <[email-masked]>
Date: Thu, 13 Oct 2005 11:33:58 -0600

I've made significant changes in authmeth-16 to this section based on
Kurt's suggestions on the Invalidated Authorization State thread.  I
believe they will resolve the concerns raised below. 

Thanks, 

Roger 

>>> Kurt D. Zeilenga <[email-masked]> 09/26/05 10:35 pm >>>
At 03:26 PM 9/22/2005, Hallvard B Furuseth wrote:
>When was this decided?  Copied from my message
><http://www.openldap.org/lists/ietf-ldapbis/200503/msg00006.html>,
>
>  The last I remember, we gave up on having invalidated associations
>  return a result to a rejected request: thread 'Result code for
>  invalidated associations', 2004.

Well, I think we did reach consensus that result codes
describe why the requested operation could be successfully
completed.  They do not generally describe the authorization
state or other session level details.  LDAP does not offer
a general mechanism for communicating authorization state
changes at the server.

>  The whole mess about them doing so
>  just got too ugly.  Instead, if a request is rejected because the
>  association is invalidated, just send Notice of Disconnection and
>  terminate the session.  I don't remember which result code we ended
>  up with; I think that issue came up in several threads.

I think part of the problem is that we're trying to oversimply
authorization state, something which is inherently complex
given multiple factors and sophisticated policy controls.

If the authorization state is such that the server doesn't
want to continue, then certainly sending a notice of disconnect
and disconnecting would be appropriate.  However, there
are cases where authorization state allows the server to
continue.  Maybe for the requested operation the server
requires new authentication and hence returns
strongerAuthRequired.  Or maybe the server just performs the
operation but at reduced authorization level (for instance,
processing a search operation as if submitted anonymously
instead under the previously established authorization
identity).  That is, some authenticated authorization states
may allow no more (maybe even less) access than some anonymous
states.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 13 Oct 2005 21:54:39 +0200

Sorry, I seem to have forgotten to reply to this one.

> a general mechanism for communicating authorization state

Yes.

> strongerAuthRequired.

But if the current authorization identity has become suspect, or the
server suspects that the client may not know that the authz id has
changed (e.g. after graceful TLS closure), then even an anonymous Bind
would fix the problem.  strongerAuthRequired would be a misleading
result code.  I think invalidCredentials was turned down for that too,
but I don't remember why.

This is a state which should be communicated to the client somehow, and
which it might be useful to have a term for - if only just to state that
this is a situation the server might need to act on.  Though perhaps
"quality of association" would have been a better term than "invalidated
association".  The quality could be OK for search but not modify, for
example.  Anyway, Notice of Disconnection if the client sends an
"unacceptable" request would be a reasonable way to handle it.

> Or maybe the server just performs the operation but at reduced
> authorization level (for instance, processing a search operation as if
> submitted anonymously instead under the previously established
> authorization identity).  That is, some authenticated authorization
> states may allow no more (maybe even less) access than some anonymous
> states.

This sounds like a *very* bad default behavour if the client has not
been informed of the auth state change.  For example, we store mail
routing, delivery and login info in LDAP.  If the auth state silently
changed, the mail system would behave as if various addresses did not
exist.  Mail to valid addresses would bounce, users could not log in.
OTOH, if the LDAP requests fail, the mail system will retry - possibly
after reporting a temporary error to the user/sender.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 13 Oct 2005 23:19:16 +0200

Roger Harrison writes:
>>>> (...)
>> You seem to be reading an old [Protocol] draft.  Protocol$,1rq(B31 does not
>> mention graceful TLS closure at all.  Protocol$,1rq(B31 StartTLS is section
>> 4.14, not 4.13.
>>
>> protocol$,1rq(Blike issues involving TLS from [protocol] to [authmeth].
>> Don't remember why.
>
> In the end, we decided to keep protocol issues in [Protocol].  Section
> 4.14.3 of [Protocol] covers removal of TLS layers.  The last paragraph
> explicitly allows either protocol peer to terminate the LDAP session after
> sending or receiving a TLS closure alert, so I believe this issue is
> resolved.

Just use the same terminology, not "graceful" closure.  That's what I
searched [protocol] for and didn't find.

What happened to text about ciphersuite renegotiations and channel
bindings, whatever that is, which Kurt has requested sometimes?

-- 
Hallvard

---

From: Howard Chu <[email-masked]>
Date: Fri, 14 Oct 2005 13:52:45 -0700

Section 3.1.5 is definitely better. A couple of minor points:
   rule #3, "leftmost RDN" is probably a bad choice. "least significant 
RDN" might be better.

X.500 never specified a left/right display order for DNs, it only 
defines them as a sequence in descending order from the root down. It 
was common practice with X.500 tools to display DNs in left-to-right 
order, like a filesystem: /rootrdn/nextrdn.../lastrdn and it was common 
for packages like (older versions of) OpenSSL to use this order as well 
when displaying DNs in X.509 certificates. While LDAP specifies a 
right-to-left order for DNs, people working with these older certificate 
management tools may still be presented with X.500-style DNs. This 
ordering ambiguity still causes a lot of confusion for users and 
administrators. I wonder if it would be worthwhile to add an explanatory 
note about this point to Appendix A.

More minor stuff:

3.1.5.2 is missing a word in the last sentence. Probably should be "A 
match occurs *if* the reference ..."

There are other missing articles/infinitives as well; I haven't finished 
reading yet.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 18 Oct 2005 16:33:29 -0600

My proposed change to [Protocol] Section 4.14.2 is this:
<old>
If the server is willing and able to negotiate TLS, it returns with the resultCode set to success. Refer to Section 4 of [AuthMeth] for details.
<new>
If the server is willing and able to negotiate TLS, it returns with the resultCode set to success. At this point the protocol peers may commence with TLS negotiation. Refer to Section 4 of [AuthMeth] for details.
 
Jim

>>> "Roger Harrison" <[email-masked]> 9/26/05 1:08:52 pm >>>

> > 3.1.2. StartTLS Response 
> > 
> >    The server will return a resultCode other than success (as 
> >    documented in [Protocol] section 4.13.2.2) if it is unwilling or 
> >    unable to negotiate TLS. In this case the LDAP session is left 
> >    without a TLS layer. 
> 
> This only says what happens at non‑success, not at success. 
> [Protocol] is rather sparse about it too. 

Based on Hallvard's query above, Jim Sermersheim and I recommend a change to paragraph 2 of [Protocol] section 14.4.2 to explicitly state that a success resultCode indicates that the protocol peers should begin TLS negotiation. I'll leave it to Jim to craft the wording. 

Thanks, 

Roger

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 18 Oct 2005 16:16:46 -0700

>If the server is willing and able to negotiate TLS, it returns with the resultCode set to success. At this point the protocol peers may commence with TLS negotiation. Refer to Section 4 of [AuthMeth…

I suggest replacing the last two sentences with:
        At this point, the protocol peers commence TLS
        negotiation as discussed in Section 3 of [AuthMeth].

It might also be appropriate to describe "this point" more
precisely, but my attempts in doing that were awkward at
best.  I do think "this point" is reasonable clear.

Kurt

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 18 Oct 2005 17:39:49 -0600

I like that better. I was tempted to clarify the "point" by changing to
something like "Upon receipt of a successful StartTLS Response, the
client may commence..." but that doesn't flow well into the pointer to
AuthMeth (because AuthMeth has instructions for both peers).

>>> "Kurt D. Zeilenga" <[email-masked]> 10/18/05 5:16:46 pm >>>
At 03:33 PM 10/18/2005, Jim Sermersheim wrote:
>If the server is willing and able to negotiate TLS, it returns with
the resultCode set to success. Refer to Section 4 of [AuthMeth] for
details.
><new>
>If the server is willing and able to negotiate TLS, it returns with
the resultCode set to success. At this point the protocol peers may
commence with TLS negotiation. Refer to Section 4 of [AuthMeth] for
details. 

Kurt

---

From: "Roger Harrison" <[email-masked]>
Date: Wed, 19 Oct 2005 17:09:50 -0600

Hallvard, 

Authmeth-16 is no longer using the term graceful closure. I believe this
issue is now adequately resolved. Please let me know if you disagree. 

I don't recall Kurt requesting text about ciphersuite renegotiations and
channel bindings in the recent past. If he is still looking for
something in this area, I'd appreciate some suggestions from him ASAP. 

Roger

>>> Hallvard B Furuseth <[email-masked]> 10/13/05 3:19 pm >>>
Roger Harrison writes:
>>>>>> Hallvard B Furuseth <[email-masked]> 09/22/05 4:26 pm
>>>

Just use the same terminology, not graceful closure.  That's what I
searched [protocol] for and didn't find.

--
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 20 Oct 2005 06:54:30 +0200

>    rule #3, "leftmost RDN" is probably a bad choice. "least significant

Simply "the RDN" (of the subjectName field) seems clearer to me.

> note about this point to Appendix A.

Sounds like a good idea.  Or a section under TLS.
Also, the quoting rules probably differ from LDAP's rules.
Something like this?

  "Note that the TLS implementation may display DNs in certificates
  according to X.509's rules rather than LDAP's rules.  For example,
  RDNs in a DN may be ordered left-to-right instead of right-to-left."

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 20 Oct 2005 07:12:23 +0200

Since Roger said protocol-like issues were moved back to [Protocol], I
suggest the last sentence in Authmeth-16 3.1.2 is moved to [Protocol]
too:

   "Authmeth-16 3.1.2. StartTLS Response

   The server will return a resultCode other than success (as
   documented in [Protocol] section 4.14.2) if it is unwilling or
   unable to negotiate TLS.  In this case the LDAP session is left
   without a TLS layer."

Then Authmeth does not need to mention non-success StartTLS at all, it
can just say that the rest of the section is about TLS issues after a
success response.

-- 
Hallvard

---

From: "Roger Harrison" <[email-masked]>
Date: Thu, 20 Oct 2005 08:15:32 -0600

I agree with Hallvard on this one. Jim, can you add the sentence, In
this case the LDAP session is left without a TLS layer, at the end of
section 4.14.2? 

Thanks, 

Roger

>>> Hallvard B Furuseth <[email-masked]> 10/19/05 11:12 pm >>>

   Authmeth-16 3.1.2. StartTLS Response

--
Hallvard

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 20 Oct 2005 09:15:27 -0600

yes

>>> Roger Harrison 10/20/05 8:15:32 am >>>

I agree with Hallvard on this one. Jim, can you add the sentence, "In
this case the LDAP session is left without a TLS layer," at the end of
section 4.14.2? 

Thanks, 

Roger

>>> Hallvard B Furuseth <[email-masked]> 10/19/05 11:12 pm
>>>

--
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Oct 2005 12:49:29 -0700

>bindings, whatever that is, which Kurt has requested sometimes? 

IIRC, I wanted to things.  One is a general note that authorization
is subject to numerous factors.  This is covered in section 3.2
and 4 (though not specifically in the latter section).  The Second
is to note that upon ciphersuite renegotiation, both peers
must again verify that resulting data security protections are
adequate.  This is kind of covered in 3.1.4.  It might also be
appropriate to note this in 3.3 as well.  Maybe just clarify:
  After TLS negotiation is completed
applies both to initial and any subsequent negotiation.
Possibly:
  s/negotiation/(initial as well any subsequent) negotiation/

It might be useful to say something about channel bindings,
but I don't have any specific suggestions at this time.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 20 Oct 2005 23:46:15 +0200

> issue is now adequately resolved. Please let me know if you disagree.

Actually, the draft still talks to about graceful TLS removal/closure
in 3.1.4 and C.0.  Don't know if that was a mistake or intentional.

It's not very important anymore, sinced the original issue is fixed.  (A
long client-specific sentence is gone, and a wrong [Protocol] section).

-- 
Hallvard

---

From: "Roger Harrison" <[email-masked]>
Date: Thu, 20 Oct 2005 16:28:02 -0600

I searched for this yesterday but must have had my search criteria
wrong. I have now fixed section 3.1.4.  Section C.0 is a historical
record of changes made to the document and will disappear as the draft
moves to an RFC, so I'm not going to change it.
 
Roger

>>> Hallvard B Furuseth <[email-masked]> 10/20/2005 3:46:15
pm >>>

It's not very important anymore, sinced the original issue is fixed. 
(A
long client-specific sentence is gone, and a wrong [Protocol]
section).

-- 
Hallvard