Am I breaking the "Law of Demeter"?

Violations of the Law of Demeter are instances of a code smell named Inappropriate Intimacy. To remove this smell, you can refactor your code by hiding the internals of address and implementing methods in Customer that delegate to address. This way, you respect the encapsulation on the address inside the Customer.

Example:

public class Customer extends ICustomer{
    private Address address;
    ....

    public void setCity(String city){
        address.setCity(city);
    }

    public String getCity(){
        return address.getCity();
    }
}

Hope this helps.

The problem here is that Address is a ValueObject. You would never change the city without changing the zip.

public class Customer extends ICustomer{
    private Address address;
    ....

    public void setAddress(String street, String city, int zip){
        address = Address.new(street, city, zip);
    }
    // or even better but i'm not sure if it's valid C#
    public void setAddress(int zip){
        address = Address.lookup(zip);
    }
}

This article: http://haacked.com/archive/2009/07/14/law-of-demeter-dot-counting.aspx has a great explanation of the issues you are discussing.

As he notes it's not a dot counting exercise, it's a coupling issue. Currently your Customer and Address classes are too tightly coupled. For starters, Customer shouldn't be making new addresses, perhaps pass an Address in using a constructor. As to whether you should be using multiple dots to access parts of the address, read the article ...

Martin Fowler: "I'd prefer it to be called the Occasionally Useful Suggestion of Demeter."