Subject: Re: [Dime]: A Potential Issue with the New Text for RFC 3558bis

From: Victor Fajardo <[email-masked]>
Date: Thu, 01 Nov 2007 08:11:43 -0400

Hi,

>
> I have noticed what appears to be an omission in 
> draft-ietf-dime-rfc3558bis.
> Whereas RFC 3558 explicitly required IPsec for the client with an 
> option for TLS, now the TLS is mentioned as an OPTION, but nothing is 
> said about IPsec. Is IPsec still mandatory? If not, is it still an 
> option? I strongly believe that the text must be explicit.
>

 From the discussion we had a few months ago, the conclusion was that 
extensive use case references to IPsec is not necessary because diameter 
has no deep protocol interaction/dependency with IPsec (unlike TLS); 
i.e. IPsec can be used independent of and transparent from diameter. 
(See http://www.tschofenig.priv.at:8080/diameter-interop/issue52). However, 
use of IPsec still remains as an option under security considerations in 
Sec 2.2 and Sec 13. What type of 'explicit text' do you have in mind ?

regards,
victor

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "Zeltsan, Zachary \(Zachary\)" <[email-masked]>
Date: Thu, 1 Nov 2007 15:33:46 -0500

Victor,

Do I understand it right then that what the current specification says
is that the client 
1) MAY use TLS , or 
2) MAY use IPsec, or 
3) Simply have no security whatsoever? 

With thanks,

Zachary

> -----Original Message-----
> From: Victor Fajardo [mailto:[email-masked]] 
> Sent: Thursday, November 01, 2007 8:12 AM
> To: Zeltsan, Zachary (Zachary)
> Cc: [email-masked]
> Subject: Re: [Dime]: A Potential Issue with the New Text for 
> RFC 3558bis
> 
> Hi,
> 
> >
>  From the discussion we had a few months ago, the conclusion 
> was that extensive use case references to IPsec is not 
> necessary because diameter has no deep protocol 
> interaction/dependency with IPsec (unlike TLS); i.e. IPsec 
> can be used independent of and transparent from diameter. 
> (See 
> http://www.tschofenig.priv.at:8080/diameter-interop/issue52). 
> However, use of IPsec still remains as an option under 
> security considerations in Sec 2.2 and Sec 13. What type of 
> 'explicit text' do you have in mind ?
> 
> regards,
> victor
> 
>

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 01 Nov 2007 16:44:18 -0400

Yes. Though there is a strong recommendation in Sec 2.2 against option 
(3) below.

regards,
victor

---

From: "Zeltsan, Zachary \(Zachary\)" <[email-masked]>
Date: Fri, 2 Nov 2007 14:37:38 -0500

Then, in my opinion, it is a step back from the RFC3588 that has
stronger security requirements (section 2.2):

"Diameter clients, such as Network Access Servers (NASes) and Mobility
   Agents MUST support IP Security [SECARCH], and MAY support TLS [TLS].
   Diameter servers MUST support TLS and IPsec.  The Diameter protocol
   MUST NOT be used without any security mechanism (TLS or IPsec)."

The draft 3588bis states only that "The Diameter protocol SHOULD NOT be
used without any security
   mechanism."

What is the reason for relaxing security?

With thanks,

Zachary
> Sent: Thursday, November 01, 2007 4:44 PM

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 2 Nov 2007 18:35:02 -0700

Personally, I think that it would both simplify things & improve security
considerably to simply make TLS a MUST & delete the mention of IPsec.

---

From: "Thomas Lindgren" <[email-masked]>
Date: Sat, 3 Nov 2007 13:56:50 +0100

> What is the reason for relaxing security?

Zachary,

While I certainly didn't write it, it does seem reasonable to me. First,
requiring support for IPSec doesn't seem like an issue that needs to be
addressed in the diameter protocol. Second, since diameter is a peer-to-peer
protocol, the distinction of requiring TLS support in 'servers' but
permitting its absence in other elements seems odd, or perhaps outdated.
Third, perhaps we will want other solutions than IPSec or the base spec TLS
usage. (How about an alternative simpler stunnel-style TLS, anyone?) So the
MUST/MAY requirements in the first paragraph seem too strong and inflexible.
Regarding the MUST NOT, I have in practice seen little demand for either
IPSec or TLS so far, so requiring it seems like overkill (or an invitation
to ignore full compliance). Thus, the second formulation seems fine to me.

(Ideally, I'd instead prefer to see the detailed transport layer security
issues moved into new RFCs instead.)

Best,
Thomas
--
Thomas Lindgren, Millpond Services Ltd
_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 05 Nov 2007 12:29:05 -0500

Hi Thomas,

> While I certainly didn't write it, it does seem reasonable to me. 
> First, requiring support for IPSec doesn't seem like an issue that 
> needs to be addressed in the diameter protocol. Second, since diameter 
> is a peer-to-peer protocol, the distinction of requiring TLS support 
> in 'servers' but permitting its absence in other elements seems odd, 
> or perhaps outdated. Third, perhaps we will want other solutions than 
> IPSec or the base spec TLS usage. (How about an alternative simpler 
> stunnel-style TLS, anyone?) So the MUST/MAY requirements in the first 
> paragraph seem too strong and inflexible. Regarding the MUST NOT, I 
> have in practice seen little demand for either IPSec or TLS so far, so 
> requiring it seems like overkill (or an invitation to ignore full 
> compliance). Thus, the second formulation seems fine to me.

I generally agree with this assessment. This was also the general 
feeling among implementors during past interops. That's why the current 
text is the way it is. Regarding 'servers' requiring TLS support, that 
can probably needs cleaning up as well.

>
> (Ideally, I'd instead prefer to see the detailed transport layer 
> security issues moved into new RFCs instead.)

regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 12 Nov 2007 09:40:34 -0500

Hi Glen,

> considerably to simply make TLS a MUST & delete the mention of IPsec.

Sounds good, though I think we should make TLS a SHOULD.

regards,
victor

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 12 Nov 2007 09:53:26 -0800

Hi Glen,

Sounds good, though I think we should make TLS a SHOULD.
[gwz] 
Aside from the fact that optional security is a _really_ bad idea, I find it
difficult to believe that this doc will make it through IESG review w/o a
mandatory-to-implement security method.  For those folks who believe that
their networks are so impregnable that they need no security, 

	1) "mandatory to implement" does _not_ mean "mandatory to deploy"
and
	2) can I get your names?  I sense a major profit opportunity...
[/gwz]
 
regards,
victor