[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RPSEC] [secdir] [sidr] Authentication for OSPFv3
- To: "Sam Hartman" <hartmans-ietf at mit.edu>
- Subject: Re: [RPSEC] [secdir] [sidr] Authentication for OSPFv3
- From: "Vishwas Manral" <vishwas.ietf at gmail.com>
- Date: Tue, 30 Sep 2008 17:08:08 +0530
- Cc: msec at ietf.org, tsvwg at ietf.org, edward.jankiewicz at sri.com, ospf at ietf.org, secdir at mit.edu, sidr at ietf.org, rpsec at ietf.org, dward at cisco.com, Sandy Murphy <sandy at tislabs.com>, rcallon at juniper.net
- Delivered-to: ietfarch-rpsec-web-archive at core3.amsl.com
- Delivered-to: rpsec at core3.amsl.com
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=eclQdtcX5SqXeFO8a1LSsbbMqeV6nrM0ZtZWnndHXUw=; b=fLkj41ai4qQEhFfVMLQuA3N3DOeXxKu4MV5V31C1/l1l+0SugITpIxXhaBujaofunG XaOUcj6f9RMZJU/UJEXYJ1+2N+9r+F/QkBxiwFhFrvfg3OBdtHjcMuUCxmBgdi9V/fMv m7Q1h/l9myrMGR/y+vUCnv9wrFhPPcDvEzhwA=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=YUrS6je77g8RgnAbuulzm48kJ5r0OpZZzG2JWa3F9y+gKMr2xn9eyBbS9JRCS9vxFU RX6uOPc9nCWavx/lLIBlUN5esnd7VaxZMFPKRBawHV60+uSHA8g3wS4L1VbiQ0j1bVIf g3BmtSCPgCvyB3G3r0Y1XEoAUfvQfyIpPkTGM=
- In-reply-to: <tsld4ilzyno.fsf at mit.edu>
- List-archive: <http://www.ietf.org/pipermail/rpsec>
- List-help: <mailto:rpsec-request@ietf.org?subject=help>
- List-id: Routing Protocol Security Requirements <rpsec.ietf.org>
- List-post: <mailto:rpsec@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=unsubscribe>
- References: <48D96507.4000207 at sri.com> <20080929200231.3E5DD3F443 at pecan.tislabs.com> <77ead0ec0809291853t63940339xc826b13cf5515176 at mail.gmail.com> <tsld4ilzyno.fsf at mit.edu>
- Sender: rpsec-bounces at ietf.org
Hi Sam,
Thanks for the queries. First off the draft is located at
http://tools.ietf.org/html/draft-manral-rpsec-existing-crypto-05 and
details issues in security even after the current set of security
mechanisms are in place. Some issues are well known in the security
community like trying to discourage the use of MD5 and instead use
HMAC-SHA1 and HMAC-MD5. We have already got drafts for the same to
support them in OSPF and ISIS.
The issue we have here is the requirement in IPsec of the deployment
of authentication identities and credentials and having a
authenticating infrastructure (trusted third-party) reachable even
before any of the routes are learned.
What I was proposing was to instead start off using IPsec in BTNS mode
(with say a GTSM check for IKE packets as the authentication mechanism
for IKE packets - and no 3rd aprty authentication) and learn routes.
Once this happens an optional second level of stronger authentication
can be done as all routes are now available (if it is so desired).
So we get the complete IPsec security - except for the fact that we
rely on TTL mechanisms for the IKE at the beginning.
Do let me know what you think about the idea?
Thanks,
Vishwas
On 9/30/08, Sam Hartman <hartmans-ietf at mit.edu> wrote:
>>>>>> "Vishwas" == Vishwas Manral <vishwas.ietf at gmail.com> writes:
>
> Vishwas> We can also solve the problem similarly by something like
> Vishwas> BTNS(ofcourse Multicast part needs to be thought further)
> Vishwas> which does not necessarily require any certificate
> Vishwas> verification - so we may have unauthenticated IKE SA's
> Vishwas> but then all keys for the CHILD_SA from there are
> Vishwas> automatically generated.
>
>
> Let me see if I understand this approach correctly. I want to
> interact with OSPF. Somehow there is a group key that is in use on my
> link. In order to obtain this key, I exchange in an unauthenticated
> BTNS-style exchange with someone, and as a result of that exchange,
> obtain the key?
>
> First, who do I perform this exchange with? Anyone who currently holds the
> key?
>
> Second, what threats does this protect against?
>
> Finally, one of the things we typically desire from BTNS-style
> protocols is a way to turn them into higher-infrastructure protocols when
> the infrastructure is available. Can I do that with your approach? How?
>
>
_______________________________________________
RPSEC mailing list
RPSEC at ietf.org
https://www.ietf.org/mailman/listinfo/rpsec