First understand BDD:

BDD is not just about testing it is a type of development practice, that avoids the difficulty of providing a definition of “Done”.

https://dannorth.net/introducing-bdd/ the author of BDD style states that:

“Behaviour” is a more useful word than “test”

Now I had a tool — agiledox — to remove the word “test” and a template for each test method name. It suddenly occurred to me that people’s misunderstandings about TDD almost always came back to the word “test”.

That’s not to say that testing isn’t intrinsic to TDD — the resulting set of methods is an effective way of ensuring your code works. However, if the methods do not comprehensively describe the behaviour of your system, then they are lulling you into a false sense of security.

I started using the word “behaviour” in place of “test” in my dealings with TDD and found that not only did it seem to fit but also that a whole category of coaching questions magically dissolved. I now had answers to some of those TDD questions. What to call your test is easy — it’s a sentence describing the next behaviour in which you are interested. How much to test becomes moot — you can only describe so much behaviour in a single sentence. When a test fails, simply work through the process described above — either you introduced a bug, the behaviour moved, or the test is no longer relevant.

I found the shift from thinking in tests to thinking in behaviour so profound that I started to refer to TDD as BDD, or behaviour- driven development.

It shows that focusing on the behavior of the system than on functionality we get more clear understanding on:

1. What to implement
2. What to test
3. What to consider as acceptance criteria for marking a story “done”
4. Where to start: keep story as the starting point , it defines what functionality and what behavior the system should have. It avoids the cases of having misunderstanding about the system and ensures there is no “absence of error fallacy” (absence of error fallacy mean there is no errors but the system itself is not usable as it was not build the way it was required to be )
5. What changes to make and what are its effect on the system behavior
6. Provides more traceability and visibility of system functionality and features
7. More test coverage traceability as you know what all scenarios or behaviors to be covered

Difference between BDD and KDT

BDD:

https://dannorth.net/whats-in-a-story/

Behaviour-driven development uses a story as the basic unit of
 functionality, and therefore of delivery. The acceptance criteria are
 an intrinsic part of the story — in effect they define the scope of
 its behaviour, and give us a shared definition of “done”. They are
 also used as the basis for estimation when we come to do our planning.
 
 Most importantly, the stories are the result of conversations between
 the project stakeholders, business analysts, testers and developers.
 BDD is as much about the interactions between the various people in
 the project as it is about the outputs of the development process.

KDT

Keyword driven testing is a way of achieving the BDD approach in testing , you can define the behavior of a system using **keyword**.

you can also do this using **Gherkin** as in cucumber

Framework like **Robotframework** supports both keyword abstraction and use of Gherkin(Given,when,then)

Summary:

BDD is a development practice where user stories are defined by defining the expected behavior of the system towards a specific action. It allows more clarity on what to develop, test and deliver.

and KDT is the approach of implementing BDD in test framework so that we get test coverage and one to one traceability with our test scripts and user stories

Gherkin is another syntactical way of defining BDD in test,

so you can use both Gherkin, Keyword driven , or simple page object method abstractions that defines behavior than functionality in your BDD test framework.

example:

As a [X]
I want [Y]
so that [Z]

where Y is some feature, Z is the benefit or value of the feature, and X is the person (or role) who will benefit. Its strength is that it forces you to identify the value of delivering a story when you first define it.

Another form of explaining behavior would be :

Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.

in both forms there is an action by the actor/user and an expected behavior from the system.

Important:

Unless the keywords or Gherkin or test methods defines the behavior of the system , non of Gherkin , Keyword driven or simple test methods cannot be considered as Behavior driven, they become just Gherkin , KDT or plain low test methods.

so not all keywords or Gherkin or test methods are BDD compliant