Subject: [midcom] R65

From: "Anderson, Todd A" <[email-masked]>
Date: Thu, 11 Oct 2001 13:45:01 -0700

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Thursday, October 11, 2001 10:25 AM
> To: midcom
> Subject: [midcom] Resolved
> 
> R65: rewritten - "The midcom protocol must provide for message
>    authentication confidentiality and integrity."

It seems to me that you wouldn't want somebody to be able to
capture an open or close pinhole/NAT binding request and play it
back at some arbitrary point in the future.  I don't think any
of the stated security properties listed above protect against
replay attacks.  My preference would be to see the "freshness"
security property added to this requirement but if people want
to make a new requirement that is fine too.

Possible attacks if freshness is not required:
1. someone captures an open request and plays it back to reopen
the pinhole after it has been closed.
2. someone captures a close request and plays it back to close
a duplicate pinhole reopened later.

Todd Anderson
Intel Labs

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom

---

From: "Christopher A. Martin" <[email-masked]>
Date: Mon, 15 Oct 2001 12:51:17 -0500

authentication methods typically include some form of hash over the
authentication field, or perhaps a separate protocol can be used such as
SSL/TLS.

If MIDCOM protocol can be implemented with SSL/TLS (i.e. is TCP
protocol)then it would naturally fit into a possible future architecture
that can also garauntee non-repudiation.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Anderson, Todd A
> Sent: Thursday, October 11, 2001 3:45 PM
> To: midcom
> Subject: [midcom] R65
>
>