Re: FW: Gen-art review of draft-ietf-netconf-beep-08.txt

[Eliot Lear <lear@cisco.com>]

Elwyn,

More discussion below.
 
> Indeed: for those of us introduced to SNMP at a tender age, manager
> and agent come naturally, but this is a mapping to NETCONF and for
> better or for worse the NETCONF WG has decided on client and server so
> I think this spec has to be couched in those terms.
If this were a small amount of work, I wouldn't argue the point.  It's a
large amount of work to rework the draft for all of that, and BEEP
specifically avoids the use of client/server terms.  This having been
said, let me propose the following wording be added as follows:

NEW S2P2:

    For purposes of this document a manager is a NETCONF client, and an
    agent is a NETCONF server.  Use of client/server language in BEEP is
    avoided because of the common notion that in networking clients
    connect to servers.


>>  
>>> The emphasis on reversability may be confusing: Checking with the
>>> NETCONF protocol, if I understand correctly, a given endpoint in a
>>> session is confined to being a client or a server.  Thus although a
>>> BEEP channel is reversible the NETCONF session that runs over it is
>>> not and indeed the transport protocol has to tell NETCONF which sort
>>> of endpoint (client or server) it is.
>>>       
>> Apparently it did not sufficiently confuse you.  You understood what we
>> meant.
>>   
> BUT only after spending a couple of hours digging into BEEP, NETCONF
> and TLS, and asking a friend.   The point is that the reversibility
> applies to who can start the connection but once NETCONF gets going a
> given channel is not reversible: getting this from the specification
> was not so easy.
With the added text I sent previously I believe this problem is now
resolved.
>>> The security considerations section specifies requirements and
>>> operations rather than just discussing the threats and their
>>> mitigation.
>>>       
>>
>> The security considerations section should be viewed in the context of
>> the base protocol.  I will not reiterate everything said there.
>>   
> That is not what I am asking for.  The whole business of managing
> certificates and what profiles are advertised are parts of the
> functionality that have to be implemented.  Looking inside the
> security considerations for this is not something that I would hope to
> have to do.
I believe I addressed this concern below.
>>  
>>> Message and object conventions:
>>> BEEP messages vs XML objects:
>>> Much as I like to see the proper pleasantries being exchanged before
>>> the manager and agent get down to business, I think that when para 1
>>> of s2.1 says 'greetings are exchanged' I think it means '(BEEP)
>>> Greeting messages are exchanged' (2 places).
>>>       
>> Yes.  I would be happy to change the text to this if there are no
>> objections.

To be clear:

Section 2.1p1:

OLD:
  greetings are exchanged, they SHOULD each announce their support for

NEW:
  BEEP greeting messages are exchanged, they SHOULD each announce their
support for

And Section 2.1p2:

OLD:
  Once TLS has been started, a new greeting is sent by both initiator

NEW:
  Once TLS has been started, a new BEEP greeting message is sent by both
initiator


>>  
>>> In para 5 of s2.1 we then have 'in the first BEEP <greeting>'.  This
>>> presumably means in the first Greeting message but it could also be
>>> talking about the <greeting> element in that message - this is a bit
>>> confusing unless you are very familiar with BEEP.  I think it would
>>> be best to say 'in the first BEEP Greeting message' here, or
>>> alternatively 'in the <greeting> element of the first BEEP Greeting
>>> message.
>>>       
>> This is in the context of the SASL and TLS profiles.  Profiles in BEEP
>> are only advertised in the <greeting> section.  The reader is assumed to
>> be familiar with RFCs 3080 and 3081.
>>  
>>> Version of SASL PLAIN to be used:
>>> This specification refers to RFC2595 but the SASL PLAIN mechanism is
>>> currently under revision (see draft-ietf-sasl-plain-08.txt).  Should
>>> this (new) specification be using the new PLAIN specification? The
>>> latter part of para 5 of s2.1 seems a bit garbled and tautologous -
>>> rework needed.
>>>       
>>
>> Unless there is a specific security concern, I would rather not further
>> block this draft.
>>   
> I noticed that Russ Housley has raised a DISCUSS in relation to the
> use of simple identity certificates for clients.  Your comment
> prompted me to go and look at what the update of PLAIN was doing and
> as a result I read:
>>    When the PLAIN mechanism is used, the server gains the ability to
>>    impersonate the user to all services with the same password
>>    regardless of any encryption provided by TLS or other network privacy
>>    mechanisms.  While many other authentication mechanisms have similar
>>    weaknesses, stronger SASL mechanisms such as Kerberos address this
>>    issue.  Clients are encouraged to have an operational mode where all
>>    mechanisms which are likely to reveal the user's password to the
>>    server are disabled.
>>   
> It occurs to me that the combination of the reversibility of BEEP,
> PLAIN and simple identity certificates is possibly a serious security
> risk. I am not a security expert but I think I could envisage an
> attack as follows:
> The attacker impersonates a server (agent) using a simple identity
> certificate and captures the password  supplied by the client. It then
> turns round and using the password and the same certificate
> impersonates a client (manager) to a different, real server (agent).
> Consequently it is not only the client end that needs more specificity
> in its certificate but also the server end.

Server-side certs are not subject to which role is played.  The draft
makes this clear.

>>
>>
>>   
>
>>> Certificate management:
>>> I was wondering whether some of the material from s5.2 of RFC3259
>>> regardsing serverName etc could be usefully repeated here?
>>>       
>>
>> Could you please be more specific as to how?
>>   
> Sorry this was a typo: I meant RFC3529!
If I understand the discussion in RFC-3529 they are virtualizing the
service.  While I have no objection in principle, I'd suggest that is a
bit of an extension and not something that need be dealt with in the
first version of the standard.  Again, I would agree that it is a good
subject for future work.

>>> Channels:
>>> If I understand correctly, everything in s2.1 leads to the first
>>> BEEP channel (channel 0) being established between a pair of
>>> elements.  I think it would be good to mention channel 0 here
>>> because otherwise it makes its first appearance in s2.4 when it is
>>> being closed.
>>>
>>> Extra channels:
>>>      
>>>>    Certain NETCONF capabilities may require additional BEEP channels.
>>>>    When such capabilities are defined, a BEEP mapping must be
>>>> defined as well
>>>>
>>>>           
>>> The phraseology used here doesn't make it very clear if this is
>>> about possible future extensions or something that already exists. 
>>> If some do exist it would be good to give an example.  I am not sure
>>> how the second sentence ties in with the original statement in the
>>> abstract i.e. that this document *is* the BEEP mapping for NETCONF! 
>>> This probably ought to go in a separate extensibility section.
>>>       
>> I would be happy to change the text to indicate that new capabilities
>> that make use of additional channels will require an update to this
>> mapping specification.
Section 2.2 second to last paragraph:

OLD:

  Certain NETCONF capabilities may require additional BEEP channels.

NEW:

  Future NETCONF capabilities may require additional BEEP channels.

>>  
>>> s2.4, Locks:
>>> A pointer to the relevant section of ref [1] talking about locks
>>> would be helpful
>>>       
>> The reader is presumed to be familiar with the core specification.
>>  
>>> s3, requirements:
>>> The material after the second sentence of the second paragraph is
>>> about requirements and specification of how TLS and SASL are  to be
>>> used.  This doesn't belong here.  It should all be specified before
>>> we get to this section.      
>> I would be happy to move this text forward to discussion of the two
>> profiles.

I see that there already exists a forward reference already in the text
in S2.1p5.  I hope this would suffice.

Thank you again,

Eliot

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