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

From: [email-masked]
Date: Wed, 12 Mar 2003 05:47:22 -0500 (EST)

>We should first say what we mean by "address based filtering". Addresses
>show up in many places performing many different roles in routing
>protocols. But phrased along the following lines I fully agree:
>"filtering based on the unauthenticated source address in the IP header
>of routing protocol messages can never be considered to provide any
>security at all; this functionality, if implemented, should be
>assumed to protect only against accidental configuration errors".

So here's the question that needs answering for the threat draft:

Do we want to separately consider a class of hosts as a distinct threat
if the only thing that makes the class different is the ability to
identify those hosts by this "no security at all" mechanism.  (A difference
that makes no difference (security wise) is no difference.)

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

---

From: [email-masked]
Date: Mon, 17 Mar 2003 18:18:46 -0500 (EST)

>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.

I guess you are say "query/response" because you are talking about something
like an LDAP server of policy rules.

But the first step uses digital signature to assure you of the authenticity
of the identity and then uses the assured identity to check the policy
rule.  The second step uses MD5 to assure you of the authenticity of the
identity and then uses the assured identity to check the policy rule where
the policy rule is "TRUE".  In other words, I think you are calling this
second case "identification" because the policy is very broad - if you
are in the group of people that know the key, you get to do anything you
want.

But nothing prevents you from having two shared keys, for "trusted" and
"super trusted" customers, with different activities authorized for each.

So the type of crypto does not dictate what policies one can enforce with
it. (Personally, myself, I'd use the stronger crypto for the broad "anything
he wants" case, but that's just me.)

So there's no difference between authorization with digital signatures and
authorization with a MD5 authentication of the identity.

--Sandy

---

From: [email-masked]
Date: Mon, 17 Mar 2003 18:24:01 -0500 (EST)

>authorization with a MD5 authentication of the identity.

Since you mention keys, I presume that you mean "keyed-MD5" (or, even better,
HMAC-MD5), and not just a MD5 hash.  Which would give you no assurance at
all of the identity.

--Sandy