ietf-openproxy
[Top] [All Lists]

Re: OCP transport nomination

2003-04-24 15:24:53

[ speaking as the beep guy, and not the co-chair... ]

 > I'm not sure how much of an advantage BEEP's security mechanisms turn
 > out to be.  It doesn't seem to have any specific support for detailed
 > security policy, ...

 nor would you want it to, given that security policies are
 either domain-specific or are so general as to lack meaning.

The expression of security policy in the TLS context comes down to a
list of cryptographic preferences.  I didn't see any way through BEEP
to encode anything about TLS negotiations.  Perhaps I'm not
sufficiently adept at BEEP navigation to find the profile document -
all I saw was a URI, and my assumption was that the single option was
"do TLS".  What document shows how to encode a request for mutual
authentication, encryption algorithm, authentication mechanism?

well, where i come from we refer to that as a negotation issue not a
matter of security policy. (although i suppose one could categorize the
former as a subset of the latter). to me a security policy refers to
things like authorization, access control, etc., which, by definition
are domain-specific.

if you look at the security considerations section of the various rfcs
that use beep (e.g., 3195, 3288), you'll see that things like
cryptographic preferences is dictated there. things like cryptographic
preferences are already encoded in the tls negotiation...
    
/mtr

<Prev in Thread] Current Thread [Next in Thread>