Subject: CAP: Security Considerations

From: Patrice Lapierre <[email-masked]>
Date: 13 Feb 2002 15:44:21 -0500

A Security Considerations section must be included in CAP.

The following requirement was posted on the list:

Doug wrote: 
> I do agree that we MUST mandate at least ONE minimum authentication
> level that CS/BEEP MUST support.  This was dictated to us by
> the area directors years ago

The following proposition is based on Marshall T. Rose suggestion:

see: http://www.imc.org/ietf-calendar/mail-archive/msg03765.html
  
-------------- 

Section X.0 Security Considerations. 

   Consult Section 2.4.2 for a discussion of access rights.
   In addition, since CAP is a profile of the BEEP, consult 
   [BEEP]'s Section 9 for a discussion of BEEP-specific 
   security issues.
   
   Although service provisioning is a policy matter, at a minimum, all
   implementations must provide the following tuning profiles:

   for authentication: http://iana.org/beep/SASL/DIGEST-MD5

   for confidentiality: http://iana.org/beep/TLS (using the
      TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher)

   for both: http://iana.org/beep/TLS (using the
      TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side
      certificates)

--------------

Questions: 
  
- Do we want to specify a minimal encryption for CAP?
  If not then we should remove the last two statements.

- Is DIGEST-MD5 the authentication mechanism we want to
  include?

--
Patrice.

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Feb 2002 14:09:24 -0700

> see: http://www.imc.org/ietf-calendar/mail-archive/msg03765.html

And what about VCAR and command security issues?

	- be careful of the GRANTs you give out ...
	
	- Use of the <identifty> command ...

	- Anonymous login ...

	- ...more?...

>   If not then we should remove the last two statements.

Yes! Otherwise any two or more implementations of TLS might
not have the same encryption and that makes things break.

> - Is DIGEST-MD5 the authentication mechanism we want to

I think so, that is what Paul had said in the past for maximum
usability mixed with desired security.

---

From: Gary Frederick <[email-masked]>
Date: Thu, 14 Feb 2002 06:19:35 -0600

>>>the area directors years ago
Why?

This prevents someone from implementing a small 'CAP' service.

What if I have something in a secure area and don't need to authenticate?

Then again, I can have something reasonably light weight and call it 
CAPLite and say it's not CAP. Mandating eliminates the need to have 
protocol and behavior to see what's on the other side.

Gary

---

From: Patrice Lapierre <[email-masked]>
Date: 14 Feb 2002 09:14:51 -0500

> >>>the area directors years ago
  I can't say, I wasn't there.

> protocol and behavior to see what's on the other side.

  CAP uses BEEP for authentication, therefore you could use another
profile for authentication. And BEEP does provide a mean for a 
CUA to determine what authentication mechanisms are available on 
the other side.

---

From: Doug Royer <[email-masked]>
Date: Thu, 14 Feb 2002 09:05:03 -0700

> >>>the area directors years ago

Because it is an IETF requirement and we will not be allowed
to become an RFC without it. We MUST mandate at least
one authentication mechanism. You can search the archives
for this discussion - it took place a year or more ago
on this list.

If there where 10 CS implementations and each used a unique
authentication mechanism - we would have NO interoperability.
And what if 10 CUA implementations used another 10 unique
authentication mechanisms, no one could use CAP at all.

And per the IETF, we can not mandate clear text authentication.

> This prevents someone from implementing a small 'CAP' service.

No, it just mandates that they are CAP servers if they conform.

> What if I have something in a secure area and don't need to authenticate?

Your are free to turn it off. The requirement says that it is
not a CAP server unless it can interoperate with any other
CAP server that is compliant to the spec.

BEEP allows for multiple authentication mechanisms, you must
at least advertise the mandated one. You are free to advertise
others.

> protocol and behavior to see what's on the other side.

If it is not CAP - then it is not CAP - what is the issue?

---

From: Gary Frederick <[email-masked]>
Date: Thu, 14 Feb 2002 11:55:38 -0600

Doug Royer wrote:

> to become an RFC without it.

Good enough for me.

> We MUST mandate at least

I was agreeing...

Gary

---

From: Patrice Lapierre <[email-masked]>
Date: 14 Feb 2002 15:55:40 -0500

> Patrice Lapierre wrote:
...
> >    Although service provisioning is a policy matter, at a minimum, 
> >    all implementations must provide the following tuning profiles:
> > 

How about rewriting the first sentence to:

   Access rights should be granted cautiously, consult
   Section 2.4.2 for a discussion of the subject.   

> 	- Use of the <identifty> command ...

Good point.

Section 6.1.3 mentions the following:

    The CS determines through an internal mechanism if the credentials
    supplied at authentication permit the assumption of the selected
    identity.  If they do, the session assumes the new identity,
    otherwise a security error is returned.

Would it be sufficient to add the following:

   The "identify" command should be carefully implemented as 
   discussed in Section 6.1.3.
    
> 	- Anonymous login ...

I think it's supported by the profile:
  
      'http://iana.org/beep/SASL/ANONYMOUS'

 I don't understand your intent, are you suggesting that
it should be added as must, or proposing to add some text 
to explain issues related to anonymous authentication?

---

From: Doug Royer <[email-masked]>
Date: Thu, 14 Feb 2002 20:24:25 -0700

> to explain issues related to anonymous authentication?

My experience tells me that the security IETF folks are
going to read this section and use it to determine
if we know what we are talking about.

Pointing to BEEP is not sufficient. We will need to say
something like:

	BEEP allows xxx authentication and we do (or do not)
	see that CAP opens up any additional security ....
or
	Or in addition to BEEP security ... if the CS
        does this xxxx then bad yyy can happen.

So it is not just an index of where to look. It its
a section where we can point out security issues for
implementers and administrators.

I don't recall that we have had this debate. And I think
the reason is that we depend on PAUL to be our expert.
I am not an expert in security.

---

From: Bob Mahoney <[email-masked]>
Date: Fri, 15 Feb 2002 11:25:18 -0500

>if we know what we are talking about.

Good assumption...  :-)

>implementers and administrators.

Yes- we need to show that we have considered all the questions, and 
detail what we have done (or refrained from doing) that will address 
them.

This section will be closely scrutinized, and you can expect that 
some conclusions will be drawn from it as to whether we have our act 
together.  Even if the document as a whole is a thing of Wonder and 
Beauty, if we attempt to hand-wave away the hard security questions, 
the document will simply not advance.

-Bob