I can't quote chapter and verse (which means I'm going to need to learn something I don't know yet!). I can relate some tidbits that would cause me to draw some tentative conclusions:
1. CMR aside, *any* field needs both an abstract accessor and an abstract mutator declared on the bean class.
2. For non-CMR fields, I've found that those accessors/mutators don't need to be declared in a local or remote interface. This is a good thing, because I don't think it makes sense to mutate a primary key field!
3. If you don't declare the CMR field on a local or remote interface, then your
Java code would not be able to navigate from one bean to the other.
4. I'm pretty sure that EJB-QL navigation from bean to bean is determined completely by the descriptor, but I haven't verified this.
5. Unlike with the primary key for the current bean, I don't think you declare the foreign-key fields (the PK fields for the bean related via CMR) anywhere. Obviously the datatabase table must contain those columns, but guess how the mapping is done must always depend upon the vendor-specific mechanism (typically an additional descriptor file). In the Java code and ejb-jar.xml file all you do is deal with a single field for the related object.
So, adding all that up I would guess you don't have to declare the relationship field in the local component interface. You'd generally want to (or you probably wouldn't have bothered with CMR), but you don't have to. For example I strongly suspect you could just provide an accessor if you didn't want a client to change the relationship.
Also remember that all bets are off with remote component interfaces - no access to CMR fields.