A first cut at capturing some RMT Security Issues

Hello Lorenzo,

I have attached a document that I started to summarize potential RMT 
security issues.  I wanted to put this in front of you before putting 
it on the list and opening an unnecessary can of worms (no pun 
intended).  This document is just an exploration of risks that I 
could think of (and those areas mentioned by Magnus and others on the 
list) ... It is basically a "Security Considerations" section on 
steroids.

I spoke with Ran Atkinson about it a little bit who has some 
experience in this area and he suggested we might want to get some 
advice from Russ Housely here.

The question that stands is:  Is specifying IPSec for authentication 
and optionally confidentiality, pointing to GSAKMP (RFC 4535) for 
automated key management sufficient for the RMT transport protocol 
instantiations?   Does that answer Magnus' concerns?

  I understand that some type of automated key management may now be 
mandatory for new protocol specifications within the IETF to make 
sure security is deployable?

I am thinking of providing updated NORM documents in this regard, but 
I know we discussed putting together some kind of RMT Security 
Analysis at the last working group meeting and the attachment is my 
first cut at that kind of thing.

(The attachment is HTML because the converter for text doesn't like 
my "included" RFC references)

FYI, I plan to post updated versions of the NORM BB & PI documents in 
the next few days.  The revised BB draft actually expired last 
weekend.  I guess I should ask for a last call after I post the 
updated, revised drafts?

I hope the summer has treated you well.

best regards,


-- 
Brian
__________________________________
Brian Adamson
<mailto:[email protected]>

_______________________________________________
Rmt mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rmt