Subject: [Seamoby] CARD: Details on signing unsolicited CARD Reply messages

From: Marco Liebsch <[email-masked]>
Date: Fri, 10 Oct 2003 18:48:39 +0200

"...Now unsolicited CARD replies are to be authenticated with signatures,
which MN can verify with the public key of the AR, that MN has learned
from somewhere. This is very vague. The description of CARD should be
sufficient for two implementations to be interoperable. IMO you should
either remove the whole unsolicited CARD reply functionality, or clarify
the use of signatures so that it will actually work between two
independent implementations."

To be honest, removing the advertisement of unsolicited CARD Replies
is not the solution I would support. 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?  

But I am also fine with adding some more details here. Any
proposals for details on a mechanisms?

marco

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Henrik Petander <[email-masked]>
Date: Tue, 14 Oct 2003 06:53:34 +0300 (EEST)

On Fri, 10 Oct 2003, Marco Liebsch wrote:
>
> 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.

> 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

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 14 Oct 2003 09:10:48 -0400

> 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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 14 Oct 2003 09:15:38 -0700

Eunsoo,

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

----- Original Message ----- 
From: "Eunsoo Shim" <[email-masked]>
To: "Henrik Petander" <[email-masked]>; "Marco Liebsch"
<[email-masked]>
Cc: "Henrik Petander" <[email-masked]>; "Seamoby"
<[email-masked]>
Sent: Tuesday, October 14, 2003 6:10 AM
Subject: Re: [Seamoby] CARD: Details on signing unsolicited CARD Reply
messages

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 14 Oct 2003 12:37:38 -0400

> should be explicitly listed as an open issue in the Security
Considerations

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

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 14 Oct 2003 19:15:24 +0200

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
>  
>
>>certificate distribution between router and host and defines a
>>    
>>
>certification
>  
>
>>should be explicitly listed as an open issue in the Security
>>    
>>
>Considerations
>  
>
>>section.
>>
>>            jak
>>    
>>
>
>James,
>
>>>>>other protocols. The question is whether or not the CARD protocol
>>>>>          
>>>>>
>spec
>  
>
>>>>>sould be specific to a solution. If there are more efficient
>>>>>          
>>>>>
>solutions
>  
>
>>>>IMO, if you have a mechanism such as the unsolicited multicast
>>>>        
>>>>
>replies,
>  
>
>>>>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,
>  
>
>>>>You could look at how TLS does this and use some PKCS standard with
>>>>        
>>>>
>RSA.
>  
>
>>>There are some examples of unsecured broadcast/multicast messages such
>>>      
>>>
>as
>  
>
>>>Router Advertisement (Mobile IP). A typical solution to secure such
>>>      
>>>
>>messages
>>    
>>
>>>behind it as you pointed out above. I am quite reluctant to put all
>>>      
>>>
>these
>  
>
>>>points out the security issue and the security mechanism is not defined.
>>>      
>>>
>>The
>>    
>>