Определимся с терминологией:

1. 
   

   Объект обладает состояние и поведение (Гради Буч)

   
   Подчеркну еще раз, объект. Не тип, не класс(класс только описывает будущий объект), а объект.
   
   
2. 
   

   Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и текущими (обычно динамическими) значениями каждого из этих свойств. (Гради Буч)

   
   
   
   
3. 
   

   Поведение - это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений. Иными словами, поведение объекта - это его наблюдаемая и проверяемая извне
   деятельность. (Гради Буч)

   
   
   
   
4. 
   

   Свойство — это член, предоставляющий гибкий механизм для чтения, записи или вычисления значения частного поля. Свойства можно использовать, как если бы они были членами общих данных, но фактически они представляют собой специальные методы, называемые методами доступа. Это позволяет легко получать доступ к данным и помогает повысить безопасность и гибкость методов. (Свойства MSDN)

   
   
   
   
5. 
   

   Свойства позволяют обращаться к методу в исходном тексте программы, используя упрощенный синтаксис. (Рихтер, глава 9, стр. 204 по книге)

   
   
   
   
6. 
   

   Осторожный подход к определению свойств. Лично мне свойства не нравятся, и я был бы рад, если бы их поддержку убрали из Microsoft .NET Framework и сопутствующих языков программирования. Причина в том, что свойства выглядят как поля, на самом деле являясь методами. Это по рождает массу заблуждений и непонимания. Столкнувшись с кодом, обращающимся к полю, разработчик привычно предполагает наличие массы условий, которые просто не всегда верны, если речь идет о свойстве. (Рихтер, глава 9, стр. 204 по книге)

   
   
   

А теперь разберемся, что к чему.
Пример из того же Рихтера глава 9.

public sealed class Employee 
    {
    private String m_Name;   // Это состояние 
    private Int32  m_Age;    // Это состояние 
    
    public String GetName() // Это поведение  
    {
       return(m_Name);
    }
    public void SetName(String value) // Это поведение
    {
       m_Name = value;
    }

Равносилен этому примеру из той же главы (Рихтер об это сам и говорит):

public sealed class Employee 
    {
       private String m_Name; // Это состояние 
       private Int32  m_Age; // Это состояние 
    
       public String Name // Это поведение  
       {
         get { return(m_Name); }
         set { m_Name = value; }
       }  
    }

Тут уже становится ясно что свойства это механизм доступа к закрытым полям, который осуществляется через методы. А значит, что Свойства это поведение. Рихтер как раз и критикует свойства, за то что они похожи на поля, а на самом деле это методы (которые предоставляет доступ к закрытым полям). Рихтер вообще предлагает убрать свойства, дабы избежать путаницы (в книге он рассматривает проблему со свойствами с другой стороны, но это еще одна грань проблем связаны с свойствами).

И, по-поводу свойства в интерфейсах, они помечаются как abstract, и выглядят примерно так:

public abstract String GetName();
public abstract void SetName(String value);

Это просто голые методы без реализации. Они не могут быть ни состояние, ни поведение, так как только ОБЪЕКТ может иметь состояние и поведение.

Экземпляр интерфейса и абстрактного класса нельзя создать, по этому к ним применение понятия состояния и поведения невозможно.