Re: CARD: Details on signing unsolicited CARD Reply messages

Sounds good. Any objections to consider this issue as closed?

If not, related text will be modified in an updated version of the document
and an explicit statement on this issue will be part of the security 
consideration
section.

marco

Eunsoo Shim wrote:

>>The example you give (Router Advertisements) is the subject of the
>>    
>>
>Securing
>  
>
>>Neighbor Discovery Working Group (SEND) for IPv6. The SEND specification
>>defines an authentication option for RAs. The protocol depends on
>>certificate distribution between router and host and defines a
>>    
>>
>certification
>  
>
>>distribution message for the local link (specifically for that, it likely
>>won't work well in multilink situations due to fragmentation). A similar
>>solution, or possibly even SEND itself for IPv6, could be used by CARD.
>>
>>That said, I agree with Henrik's point that it can be left open, but it
>>should be explicitly listed as an open issue in the Security
>>    
>>
>Considerations
>  
>
>>section.
>>
>>            jak
>>    
>>
>
>James,
>
>It is fine with me to leave it as an open issue in the Security
>Considerations section. It is what I said anyway in my previous email.
>So I guess Henrik, Vijay, you and I are all in the same page. I remember it
>was also an option positively considered among the authors of the draft.
>
>Eunsoo
>
>  
>
>>----- Original Message ----- 
>>From: "Eunsoo Shim" <[email protected]>
>>To: "Henrik Petander" <[email protected]>; "Marco Liebsch"
>><[email protected]>
>>Cc: "Henrik Petander" <[email protected]>; "Seamoby"
>><[email protected]>
>>Sent: Tuesday, October 14, 2003 6:10 AM
>>Subject: Re: [Seamoby] CARD: Details on signing unsolicited CARD Reply
>>messages
>>
>>
>>    
>>
>>>>>The issue of authentication of advertised messages is common to many
>>>>>other protocols. The question is whether or not the CARD protocol
>>>>>          
>>>>>
>spec
>  
>
>>>>>sould be specific to a solution. If there are more efficient
>>>>>          
>>>>>
>solutions
>  
>
>>>>>in the future, why not keeping the flexibility to adopt the CARD
>>>>>protocol to that mechanism?
>>>>>          
>>>>>
>>>>IMO, if you have a mechanism such as the unsolicited multicast
>>>>        
>>>>
>replies,
>  
>
>>>>which cannot be secured with standard security protocols, then the
>>>>security mechanism should be specified in the protocol spec for
>>>>interoperability. If interoperability is not needed, then it can be
>>>>        
>>>>
>left
>  
>
>>>>open.
>>>>
>>>>Vijay's suggestion, to just say that the mechanism is not defined
>>>>        
>>>>
>here,
>  
>
>>>>might be an easy way to handle this issue and maybe sufficient for an
>>>>experimental RFC.
>>>>
>>>>        
>>>>
>>>>>But I am also fine with adding some more details here. Any
>>>>>proposals for details on a mechanisms?
>>>>>          
>>>>>
>>>>You could look at how TLS does this and use some PKCS standard with
>>>>        
>>>>
>RSA.
>  
>
>>>>This would still leave open how MN learns the public key of AR.
>>>>
>>>>        
>>>>
>>>Henrik,
>>>
>>>There are some examples of unsecured broadcast/multicast messages such
>>>      
>>>
>as
>  
>
>>>Router Advertisement (Mobile IP). A typical solution to secure such
>>>      
>>>
>>messages
>>    
>>
>>>is using public key to authenticate the messages but it could be a quite
>>>heavy computation for the MN. Also it requires a key distribution system
>>>behind it as you pointed out above. I am quite reluctant to put all
>>>      
>>>
>these
>  
>
>>>issues into the CARD protocol specification at this stage. If any good
>>>solution to secure such broadcast/multicast messages comes up, we could
>>>revise the specification later to incorporate it.
>>>
>>>So I'd support Vijay's suggestion that the current specification simply
>>>points out the security issue and the security mechanism is not defined.
>>>      
>>>
>>The
>>    
>>
>>>statements can be inserted into the "security considerations" section.
>>>
>>>Eunsoo
>>>
>>>
>>>
>>>_______________________________________________
>>>Seamoby mailing list
>>>[email protected]
>>>https://www1.ietf.org/mailman/listinfo/seamoby
>>>
>>>      
>>>
>>    
>>
>
>  
>