Re: draft-josefsson-sasl-external-channel-03

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:

> On Sat, Apr 18, 2009 at 12:44:09PM +0200, Simon Josefsson wrote:
>> Complete diff:
>> http://josefsson.org/external-channel/draft-josefsson-sasl-external-channel-03-from-2.diff.html
>> 
>> > http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-03.txt
>
> A few comments:
>
>  - I doubt today there's ever any cases where there could confusion as
>    to what channel "EXTERNAL" refers to.  The confusion and the need for
>    a priori agreement is theoretical -- if so then the text should
>    probably reflect that, otherwise examples should be given.

I don't follow -- RFC 4422 implies that the selection of what EXTERNAL
refers to needs to be arranged out of band.  The point of this document
is to move the negotiation in band.  Since RFC 4422 rules the
negotiation out of scope, there is by definition always confusion which
channel is intended, and even on successful authentication there is in
practice no in-band guarantees that both sides intended the same
channel.

Maybe Kurt could describe his use case?

>  - When "EXTERNAL" is used one would think that the highest-layer,
>    innermost end-to-end channel is the one it ought to refer to.  It
>    strikes me as a good idea to state that.

This is mentioned in section 3 for EXTERNAL-TLS.  I believe this belongs
in each EXTERNAL-FOO mechanism rather than in the generic framework, but
I agree that this needs to be stated.  I have added this section:

  <t>The external security channel to use is implied by the SASL
    mechanism name.  The channel has to be uniquely identifiable at
    both cliend and server side.  This means that mechanisms
    registered in this family MUST detail which channel should be
    chosen if there are layered channels of the same type.</t>

>  - An informative reference to TLS (RFC5246) seems necessary.  (Or
>  maybe even normative.)

I've made it normative.  (There was an informative reference.)

>  - The string "a002" in the example given should probably be explained,
>    or even removed (it seems superfluous, besides, 

It can't be removed, or the example wouldn't be valid ACAP, if I
understand correctly.  The same is in RFC 4422.  I don't think we need
to explain the ACAP protocol.  But maybe I'm missing something...

>  application protocol bindings of SASL are not needed in order to have
>  an example, no?).

...because I don't understand what you mean here, explain?

/Simon