Subject: Re: last call comments on the mapping documents

From: Eliot Lear <[email-masked]>
Date: Wed, 09 Mar 2005 15:54:35 -0600

Juergen,

Just to be clear:

> a) This document uses the "application protocol" terminology which I
>    dislike (see also my comments on the NETCONF protocol definition).
> 
> b) Section 1.1:
> 
>             This "bidirectionality" allows for either side to play
>     the role of the manager with no protocol changes.  Either side can
>     open a channel. Either size could initiate an RPC.
> 
>    I think the text confuses BEEP's capability to initiate a session
>    from either side with the manager/agent roles actually being used.
>    Perhaps the text simply wanted to say:
> 
>             This "bidirectionality" allows for either side to 
>     open a channel.
> 
>    The rationale here is that NETCONF clearly assumes manager/agent
>    roles and it is rather clear who initiates NETCONF transactions.

I've changed the text here to say as follows:

   This "bidirectionality allows either manager or agent to initiate a
   connection.
> 
> c) Section 1.1:
> 
>     This is
>     particularly important to support operational models that involve
>     small devices connecting to a manager, and those devices that must
>     reverse the management connection in the face of firewalls and NATs.
> 
>    I suggest to remove the work "small" as it does not really add
>    value - I might actually have a big device that prefers to take the
>    initiative (and how decides what small is anyway?).

Ok, I've removed the word small, as it clearly didn't impart what I was 
thinking, which is large numbers of intermittantly connected devices. 
New text will read as follows:

>     This is particularly important to support large number of
>     intermittantly connected devices, as well as those
>     devices that must reverse the management connection in the face of
>     firewalls and NATs.

> 
> d) Section 1.1:
> 
>     The SASL profile used by BEEP allows for a simple and direct mapping
>     to the existing security model for CLI, while TLS provides a strong
>     well tested encryption mechanism with either server or server and
>     client-side authentication.
> 
>    I learned in the ISMS WG that SASL over TLS is not necessarily
>    secure. Has beep fixed this problem or do we better explain the
>    issue here and/or in the security considerations section?

Can you please elaborate?  I can envision problems where if client-side 
certificates are in use and EXTERNAL SASL was in play.  Is that what you 
are referring to?  Wes would you care to comment?

> 
> e) Section 2.1: Is the "should" in this section actually a SHOULD?

It's a SHOULD.

> 
> f) Section 2.2:
> 
>     The manager now establishes an NETCONF a new channel.
> 
>    Replace with:
> 
>     The manager now establishes a new channel.

Ok.

> 
> g) Section 2.3:
> 
>    I suggest to write NETCONF XML elements exactly as defined in the
>    NETCONF specification. Thus, <RPC> should be written in lowercase
>    as <rpc>.

That was the intent.  Thanks.

> 
> h) Section 2.3:
> 
>    There is an odd line break in the last sentence of this section.

Probably a tool issue.  I'll check it.
> 
> i) Section 2.5:
> 
>     There are two commands in the BEEP profile.  <rpc> and <rpc-reply>.
> 
>    I am not a BEEP expert, but I am wondering how the <hello> messages
>    are mapped to BEEP. Should the DTD not specify something for them?

Yep.

>    Note that I did not check the DTD as I am not a BEEP expert. Perhaps 
>    /mtr should take a look at it. Note that there are some minor
>    indentation oddities in the DTD part.

Good idea.

> 
> j) What is really missing in the whole document is an example. Ideally,
>    one would simply use the example contained in the ssh mapping 
>    document and show the same example in the BEEP mapping. This would
>    add quite much clarity and allows people to better understand how
>    NETCONF over BEEP messages will actually look like on the wire.

Yes.  I am going to add some examples, specifically as relates to SASL, 
<hello>, and perhaps a simple operation.

> 
> k) Section 4:
> 
>    I think it is important to tell IANA precisely that a port number
>    for NETCONF over BEEP/TCP is requested. Or do we assume that all
>    NETCONF over xxxx/TCP mappings share the same port number?

Absolutely not!  I have already filled out a template and will modify 
the IANA considerations accordingly.

> 
> In summary, I think the BEEP mapping document still needs some work.
> Especially an example is missing in my view and the DTD stuff probably
> needs a bit more work and proof checking.

Ok.  Draft to follow.

Thanks,

Eliot

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Mar 2005 11:57:15 +0100

> are referring to?  Wes would you care to comment?

My understanding is that common SASL usage in combination with TLS 
lacks a cryptographic binding of the authentication exchange with 
the underlying secure transport. Wes surely can explain that better
than I can do. I am just wondering whether BEEP "suffers" from the
same problem or not.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Mar 2005 14:08:31 -0600

Yes, I could understand a concern here if you are "borrowing" external 
principle names from TLS to use in SASL.  Wes, is that the concern?

Eliot

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 10 Mar 2005 13:37:13 -0800

>>>>> On Thu, 10 Mar 2005 11:57:15 +0100, Juergen Schoenwaelder <[email-masked]> said:

Juergen> My understanding is that common SASL usage in combination
Juergen> with TLS lacks a cryptographic binding of the authentication
Juergen> exchange with the underlying secure transport. Wes surely can
Juergen> explain that better than I can do. I am just wondering
Juergen> whether BEEP "suffers" from the same problem or not.

TLS/SASL alone do not contain the required cryptographic binding
needed to make the protocol secure.  Any protocol that wants to
use/allow-for that combination needs to do so itself.  I'm not sure
whether or not the BEEP document deals with this or not, and I'll have
to go look to find out.  I've put it on my todo list for next week.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 10 Mar 2005 13:44:01 -0800

>>>>> On Thu, 10 Mar 2005 14:08:31 -0600, Eliot Lear <[email-masked]> said:

Eliot> Yes, I could understand a concern here if you are "borrowing" external 
Eliot> principle names from TLS to use in SASL.  Wes, is that the concern?

A reference that may help (note that SASL is "tunneled" in this
example since it is an "external" mechanism within TLS and not
integrated):

http://www.saunalahti.fi/~asokan/research/mitm.html