Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources

From: [email-masked]
Date: Fri, 14 Mar 2003 16:55:17 -0500 (EST)

>You are right. IMHO, however, this is because in most IGPs, authentication
>(such as MD5) is used a mechanism of authorization, instead of
>identication. And current implementations just don't care the
>identification in most cases.
>
>But in the future, we might also want to care about the identification as
>well.

There are two reasons for doing authentication of identities: that you
have an authorization policy to enforce, and that you are doing auditing.

So if you are doing authorization, then you sure want to be sure that
you know that you are communicating with the authentic person.  Even if
your authorization policy is so broad that it is just "only these people
are allowed to send me packets", you still need authentication.

If you are doing logging/auditing (see also: accounting), then you sure
want to be sure that the entries you are making are correct.  So you
need authentication there, also.

So I don't know what you mean by "its used for authorization but at some
point we'd want to do identification"  For what reasons would we be doing
identification (and why do you consider that different from authorization)?

>I agree w/ you using a pure address filtering mechanism is insecure. But I
>don't think it is the only mechanism to seperate masqueraders from the
>unauthorized. For example, digital signature can be used for
>identification while MD5 can be used for authorization.

I don't understand this comment at all.  Can you explain what you mean by
digital signatures being used for identification only (I presume you mean
identification but not authorization) while MD5 was used for authorization
(I presume you mean not identification)?

--Sandy
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Yi Yang <[email-masked]>
Date: Fri, 14 Mar 2003 17:33:03 -0500 (EST)

Sandy,

> identification (and why do you consider that different from authorization)?

Let's say we want to do some policy routing based on identity. So when a
router receives an routing message, the router needs to:

1 know and verify the originator of the message; and
2 verify the originator has been authorized to send this type of message

The first step can be done w/ digital signature and the second step can be
done w/ checking a policy database. But the query/response process might
be slow.

Or, the administrator can just assign a MD5 password to the originator to
authenticate its packets. When the receiver verified the digest, it
believes that the originator has been authorized.

A similar example in the real world is the badges are being used. The
pictures on the badge are used for identification and the
shape/color/barcode decide the authorization. Permitted or not to enter a
lab is the policy routing.

Yi

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Mar 2003 10:28:03 -0500

>done w/ checking a policy database. But the query/response process might

this seems to assume checking of some remote database, right? 

>believes that the originator has been authorized.

This runs counter to what appear to be unstated assumptions in your 
previous paragraph. A MAC is not a signature and a major difference 
is that the holder of a public key can verify but not forge a 
signature, whereas the holder of a key for a MAC can both verify and 
generate the MAC. Thus MACs are point-to-point authentication 
mechanisms, but not multicast authentication mechanisms. In most 
routing protocols multiple entities must verify an assertion of a 
router, making MACs inappropriate authentication mechanisms for these 
contexts.

Steve

---

From: Yi Yang <[email-masked]>
Date: Mon, 17 Mar 2003 13:55:47 -0500 (EST)

Steve,

> this seems to assume checking of some remote database, right?

Yes.

> router, making MACs inappropriate authentication mechanisms for these

How about this way: Use MAC as a proof of authorization and use private
key to sign this MAC to prevent masquerading? Of course, we don't have to
use MAC for authorization. The administrator can assign a private/public
key to a group as authorization, so the routers in the group can share the
same key for authorization, while each member use its individual key for
identification.

Back to the original question: Should we to distinguish unauthorized
routers/masquerading routers? I think we should.:-)

Yi

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Mar 2003 14:18:28 -0500

>same key for authorization, while each member use its individual key for

The words you use above do not match normal security terminology use. 
MACs are not signed, Generally. MACs are integrity/authentication 
mechanisms. Keys do not intrinsically provide authorization. What we 
usually do is map possession of a key to an identity (for one 
person/device or a group) and then we use an authentication identity 
to make an access control (authorization) decision.

>routers/masquerading routers? I think we should.:-)

Yes, to the extent that we first authenticate a router and then we 
separately decide what the router is authorized to do.

Steve

---

From: Russ White <[email-masked]>
Date: Wed, 19 Mar 2003 19:11:51 -0500 (EST)

> separately decide what the router is authorized to do.

In other words, there is a difference between a valid member of the routing
system, and a valid member of the routing system doing calid things.

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Mar 2003 19:14:04 -0500

>system, and a valid member of the routing system doing calid things.

exactly

---

From: Yi Yang <[email-masked]>
Date: Thu, 20 Mar 2003 14:31:00 -0500 (EST)

Steve,

> The words you use above do not match normal security terminology use.

Thank you for correcting me. Need to read RFC2828 again and use words
more carefully.:-)

> separately decide what the router is authorized to do.

I agree.:-)

Yi