Subject: [AAA-WG]: Issue 59: e2e mandatory status

From: Pat Calhoun <[email-masked]>
Date: Fri, 8 Jun 2001 07:23:37 -0700

I believe that the Minn meeting minutes show that cms is
mandatory to implement. This issue is asking whether this
was the correct decision.

Could we get some WG discussions on this? I'd like to
get some agreement, and close this issue.

Thanks,

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 8 Jun 2001 08:33:13 -0700 (PDT)

> get some agreement, and close this issue.

At IETF 50, we discussed this issue and were given guidance by the IESG
that e2e security would need to be mandatory. The question is where. I
would suggest that Relays and Re-directs have no need to implement e2e
security. Servers MUST implement it -- and since proxies act as servers,
that includes them too. 

The interesting question is whether NASes MUST implement e2e
security. This seems somewhat too harsh to me, because some are quite
modest devices (e.g. Access Points selling for $250). Also, it is likely
that proxies will frequently be the endpoint for e2e, not NASes, purely
for the purpose of manageability (don't have to put certs on every NAS,
etc.). So this might be a SHOULD.

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 8 Jun 2001 09:29:46 -0700

> security. Servers MUST implement it -- and since proxies act as servers,

See the CMS I-D on a relay initiating a CMS session on behalf of the access
device.

> etc.). So this might be a SHOULD. 

I am ok with the NAS being a SHOULD, but operators will have to ensure that
some device in their network supports it.

PatC

---

From: "Jari Arkko" <[email-masked]>
Date: Mon, 11 Jun 2001 22:39:23 +0300

>The question is where.

Yes!

> security.

Right.

>Servers MUST implement it -- and since proxies act as servers,
> that includes them too. 

Sounds ok.

> etc.). So this might be a SHOULD. 

I support SHOULD.

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 10 Jun 2001 21:02:05 +0100

One note,

> > etc.). So this might be a SHOULD.

A NAS can easily support parts of the CMS app. Basically, the difference
is whether the NAS has a private key or not. If it hasn't then the 
configuration of the NAS for CMS only requires static data like root 
CA keys and the only cost that'd possibly appear in the $250 is code 
footprint. (In case someone's skeptical about this, mobile phones also 
cost about that amount and some include similar functionality.)

Also worth noting is that there's really not that much additional 
footprint required if you add the private key operations. The costs
related to private key support are largely around provisioning and
the like. ('Course if someone wants to save some dosh, leave a space
for a WIM chipcard in your NAS - there'll be lots of them about.)

On this basis, my preference would be to make support for the CMS app 
a MUST, but to explicitly call out (wherever the text goes - where's
that?) that even with the CMS app code present, you can't assume that 
a private key is actually present - this means that a conformant NAS 
can be developed, configured and used without incurring the costly 
side of the CMS app. (which is NAS-specific provisioning)

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 12 Jun 2001 06:40:57 +0300

> is whether the NAS has a private key or not. If it hasn't then the 

Well, this is one aspect but there aren't there also issues in making e.g.
a 50k-port NAS be prepared to do PK cryptographic operations per each call
(worst case call distribution to different end servers etc)? Note that h2h security
would be set-up just once at boot time, or might even be statically keyed in the
case of IPsec.

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Jun 2001 09:10:21 +0100

Jari,

> would be set-up just once at boot time, or might even be statically keyed in the

With the algorithm we're using (RSA) public key operations aren't
much slower than the symmetric crypto that'll be used for h2h. Private
key operations OTOH are expensive on a less capable CPU, which is what
I guess you mean. Bottom line is that this can be treated the same as 
the issue as I raised in my last mail (provisioning).

Stephen.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 12 Jun 2001 20:24:05 -0700

Jari Arkko [mailto:[email-masked]] writes:

<text elided>

> > etc.). So this might be a SHOULD.

I have no big problem with this, as long as there is a discussion of the
risks involved in relying upon an intermediary for "end-to-end" security
placed in (at least) the Security Considerations" section.

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 15 Jun 2001 00:02:29 +0300

Submitter name: Jari Arkko
Submitter email address: [email-masked] 
Date first submitted: 14-June-2001 
Reference: 
Document: cmssec
Comment type: editorial (?)
Priority: 2 
Section: 1 & 4
Proprietary Tag: C 
Rationale/Explanation of issue: 

- Figure 3 still uses ESSR term, should be DSAR. Search for
  more instances just to make sure there are none...

- Last paragraph of 1.2, "Allowing the first hop agent to use
  establish the DSA" seems to have some strange wording?
  => "... to be used to establish ... "?

-  PDSA has the CMS-Signed-Data AVP which I believe
   shouldn't be there. The security is from the proxy to the home,
   so no signatures for the NAS in this case. Right? Same issue
   for PDSA and Expected-*-AVP.

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 15 Jun 2001 00:12:41 +0300

There seems to be two uses of MIME in the spec, first in the beginning
of 6.1 the AVPs are MIME-encoded. Then in the end of 6.1 the
CMS-Encrypted-Data AVP is pkcs7-mime encoded. At the beginning
of 6.1 we also have some explanation that S/MIME toolkits can be used
unchanged. Is this the reason for going through MIME always, or are there
others? Is the ability to put in multiple AVPs dependent on MIME multipart?
Has someone actually verified that most S/MIME toolkits don't allow you
direct CMS operations?

Jari

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 15 Jun 2001 00:21:01 +0300

Comment type: Technical 
Section: 4.3

If the DSAR-Target-Domain was optional instead of mandatory
in PDSR, then a NAS could give the proxy full responsibility to
handle the CMS security towards the home for all domains. Today,
the NAS has to initiate a PDSR-PDSA pair for each new domain
it sees. Even if the CMS security association already existed
between the local domain's proxy and the home... after all, it is
likely that an aggregation point would already have seen the
domain.