Subject: [Dime] Options for securing CER/CEA

From: Victor Fajardo <[email-masked]>
Date: Tue, 25 Nov 2008 10:11:07 -0500

Filtering through the discussions in the list and opinions in ietf73, we 
now have the following options for securing CER/CEA:

1. Define a new secured port for diameter used only for TLS. This 
deprecates inband-security and moves TLS setup before any diameter 
traffic is sent. Its the cleanest solution and would completely secure 
CER/CEA but it would have greater backward compatibility issues.

2. Redefine the semantics of inband-security. In this case, if 
inband-security is set to TLS then it means the connecting peer must use 
TLS instead of treating inband-security as just an advertised value. TLS 
setup will still be done after CER/CEA negotiation; the way its 
currently done. There will still be some backward compatibility issue 
but implementations may not require as much change as (1).

Give the changes that's already been introduced in bis that impacts 
existing implementations, option 2 seems attractive. Though other folks 
may have other opinions or alternatives.

Any suggestions ?

regards,
victor
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Stefan Winter <[email-masked]>
Date: Tue, 25 Nov 2008 16:13:47 +0100

Hi,

> inband-security is set to TLS then it means the connecting peer must
> use TLS instead of treating inband-security as just an advertised
> value. TLS setup will still be done after CER/CEA negotiation; the way
> its currently done. There will still be some backward compatibility
> issue but implementations may not require as much change as (1).
>
> existing implementations, option 2 seems attractive. Though other
> folks may have other opinions or alternatives.

In the meeting, we also spoke about a new "STARTTLS" command code which
optionally comes before the CER which *might* be completely backwards
compatible. I had the impression that this had some support in the room.
What do you think?

Stefan

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 25 Nov 2008 11:06:23 -0500

Hi Stefan,

> compatible. I had the impression that this had some support in the room.

Good point. I was contemplating it and that maybe a good 3rd option 
which I failed to mention. In which case, we maybe able to define a new  
extension document that negotiates security and uses a new command 
code/avps as you mentioned. We may not need to do anything with bis 
except update the security considerations section to reflect the 
existing vulnerability and that extensions are available to help. Is 
this a good approach ?

regards,
victor

---

From: Jan Nordqvist <[email-masked]>
Date: Tue, 25 Nov 2008 11:04:05 -0800

As I expressed in my previous email on this subject, item 2 is the only 
option that follows the P2P connection setup mechanism architected for 
Diameter and avoids unnecessary "cross handshaking" during race 
conditions. How important this is can be argued but it *could* be a 
concern for handhelds or other devices with limited processing resources.

Another aspect of this is how may implementations out there already have 
a working implementation based on TLS after the Capabilities Exchange 
and I believe there are a few. At least our server has a complete and 
working implementation based on this mechanism.
If the initial CER/CEA handshake contains only minimal information to 
get TLS going and another CER/CEA exchange is allowed to take place 
inside the encrypted tunnel (which it used to be and likely presents a 
minimal change to any existing implementation would it be reinstated), 
that initial CER/CEA *is* your start-TLS mechanism.

In addition, using a predefined secured port will certainly create 
challenges for SCTP over TLS. The CER/CEA setup method at least lets the 
two SCTP peers negotiate in and out streams before attempting to 
establish TLS over them. There is an obvious lack of strong 
standardization text in this arena but there is still enough to 
interoperate TLS over SCTP using this method.

So if the purpose of this thread is to collect opinions, my vote is for 
"p2p start-TLS", i.e. item 2, with the addition of a secondary CER/CEA.

Jan Nordqvist
Alcatel-Lucent 8950/AAA Product Group.

Victor Fajardo wrote:
> which I failed to mention. In which case, we maybe able to define a 
> new  extension document that negotiates security and uses a new 
> command code/avps as you mentioned. We may not need to do anything 
> with bis except update the security considerations section to reflect 
> the existing vulnerability and that extensions are available to help. 
> Is this a good approach ?
>
> regards,
> victor
>
>
>> Stefan
>>
>>   
>

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 25 Nov 2008 11:11:04 -0800

Victor Fajardo [mailto://[email-masked]] writes:

> use

How does this protect the CER/CEA exchange?

> existing implementations, option 2 seems attractive. 

I'm not sure why you say that.  If bis had _not_ required any changes to
existing implementations then I would agree, but given that it has, what's
the big problem w/another?

> Though other folks may have other opinions or alternatives.
> 
> Any suggestions ?

There is a third option which could (if necessary) preserve complete
backward compatibility (I think): define a new command that simply starts
TLS, coming before any other messages.

...

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 25 Nov 2008 14:31:37 -0500

Hi Jan,

> As I expressed in my previous email on this subject, item 2 is the 
> only option that follows the P2P connection setup mechanism 
> architected for Diameter and avoids unnecessary "cross handshaking" 
> during race conditions. How important this is can be argued but it 
> *could* be a concern for handhelds or other devices with limited 
> processing resources.

Just for my understanding, in which scenario would the possible race 
condition and cross handshaking occur.

>
> Another aspect of this is how may implementations out there already 
> have a working implementation based on TLS after the Capabilities 
> Exchange and I believe there are a few. At least our server has a 
> complete and working implementation based on this mechanism.
> challenges for SCTP over TLS. The CER/CEA setup method at least lets 
> the two SCTP peers negotiate in and out streams before attempting to 
> So if the purpose of this thread is to collect opinions, my vote is 
> for "p2p start-TLS", i.e. item 2, with the addition of a secondary 
> CER/CEA.

Ok. Your vote is duly noted :) Just an additional query, your not too 
concerned about backward compatibility issues in the above scheme. Note 
that  folks have already agreed to remove CER/CEA exchange in the open 
state which poses a problem with the secondary CER/CEA.

One advantage I see in the third option (stated by Stefan) is that we 
maybe able decouple this issue from CER/CEA without imposing possible 
interoperability issues.

regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 25 Nov 2008 14:37:51 -0500

Hi Glen,

> How does this protect the CER/CEA exchange?

Its not a complete protection of CER/CEA but a mere indication that TLS 
is is coming next.

> TLS, coming before any other messages.

Yup. Pls see my other email in response to Stefan and Jan ....

-- victor

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 25 Nov 2008 14:39:39 -0500

I would prefer 1. It is clean and straightforward. I guess 2. is not
really secure as Glen pointed out -unless I am missing something-.

Thanks,
Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Victor Fajardo
> Sent: Tuesday, November 25, 2008 10:11 AM
> To: [email-masked]
> Subject: [Dime] Options for securing CER/CEA
> 
use
> existing implementations, option 2 seems attractive. Though other
folks

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 25 Nov 2008 11:39:49 -0800

...

> existing vulnerability and that extensions are available to help. Is

Although the StartTLS approach has the benefit of preserving
backward-compatibility, I believe that it will reduce the window of
vulnerability but may not close it completely.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 25 Nov 2008 14:41:13 -0500

Jan,

One question below.

Thanks,
Tolga

Of
> Jan Nordqvist
> Sent: Tuesday, November 25, 2008 2:04 PM
> To: [email-masked]
> Subject: Re: [Dime] Options for securing CER/CEA
> 
only
> Another aspect of this is how may implementations out there already
have
> challenges for SCTP over TLS. The CER/CEA setup method at least lets
the
> interoperate TLS over SCTP using this method.
[TOLGA]Streams are negotiated during SCTP association establishment.
What does CER/CEA have to do with this?
> So if the purpose of this thread is to collect opinions, my vote is
for

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 25 Nov 2008 14:44:57 -0500

Hi Tolga,

> really secure as Glen pointed out -unless I am missing something-.

Just in case you did not see it, what do you think about the 3rd option 
(already stated by Stefan and then Glenn) ?

-- victor

>> Filtering through the discussions in the list and opinions in ietf73,
>>     
> we
>   
>> TLS instead of treating inband-security as just an advertised value.
>>     
> TLS
>

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 25 Nov 2008 11:48:39 -0800

> (already stated by Stefan and then Glenn) ?

Just to be clear, I prefer #1 as well.

...

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 25 Nov 2008 15:23:52 -0500

Hi Victor,

I think STARTTLS should work but what does it buy to us in addition to
functionality provided with multiple ports?

IMO different ports approach is not too bad from backward compatibility
perspective. If a client wants to use TLS it will try the tls-port. If
there is no answer, which means the server is not updated, it will try
the non-secure port and will happily communicate with the server
(exposed to attacks during capability exchange).

After thinking a bit more I *guess* 2. would work as well but I don't
see how it is backward compatible. CER wasn't allowed in Open state in
RFC3588 AFAIR. BTW, using the intiial CER/CEA exchange in lieu of
STARTTLS is really ugly. 

So, at the end I am still in favor of 1. I don't think this is also a
modest change from coding perspective.

Thanks,
Tolga

> From: Victor Fajardo [mailto:[email-masked]]
> Sent: Tuesday, November 25, 2008 2:45 PM
> To: Asveren, Tolga
> Cc: [email-masked]
> Subject: OFFLINE: Re: [Dime] Options for securing CER/CEA
> 
> Hi Tolga,
> 
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 25 Nov 2008 15:25:38 -0500

Typo corrected:

I think this is also a modest change from coding perspective.

Thanks,
Tolga

Of
> Asveren, Tolga
> Sent: Tuesday, November 25, 2008 3:24 PM
> To: Victor Fajardo
> Cc: [email-masked]
> Subject: Re: [Dime] OFFLINE: Re: Options for securing CER/CEA
> 
> Hi Victor,
>

---

From: Jan Nordqvist <[email-masked]>
Date: Tue, 25 Nov 2008 13:25:03 -0800

Hi Victor,

The race condition occurs when two peers tries to connect to each other 
at approximately the same time, i.e. before either side has detected an 
incoming connection from the remote. This is obviously the issue that 
the election process tries to deal with.

I don't know what reasoning was behind the removal of the open state 
CER/CEA, but at least in our implementation a secondary exchange would 
have marginal impact.

Regards,
 Jan.

Victor Fajardo wrote:
>> inside the encrypted tunnel (which it used to be and likely presents 
>> a minimal change to any existing implementation would it be 
>> reinstated), that initial CER/CEA *is* your start-TLS mechanism.
>>
> concerned about backward compatibility issues in the above scheme. 
> Note that  folks have already agreed to remove CER/CEA exchange in the 
> open state which poses a problem with the secondary CER/CEA.
>
>>> with bis except update the security considerations section to 
>>> reflect the existing vulnerability and that extensions are available 
>>> to help. Is this a good approach ?
>>>
>>> regards,
>>> victor
>>>
>>>
>>>> Stefan
>>>>
>>>>   
>>>

---

From: Jan Engelhardt <[email-masked]>
Date: Tue, 25 Nov 2008 22:31:46 +0100 (CET)

On Tuesday 2008-11-25 20:04, Jan Nordqvist wrote:
> challenges for SCTP over TLS. The CER/CEA setup method at least
> lets the two SCTP peers negotiate in and out streams before
> attempting to establish TLS over them.

So it makes best sense to do TLS at the SCTP substream level
so that you can have mixed encryption/nonencryption in an
SCTP connection.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 25 Nov 2008 13:47:10 -0800

> the election process tries to deal with.

Right, so it seems that the same technique could be used if both peers sent
their hostnames in the StartTLS exchange.

...

---

From: Jan Nordqvist <[email-masked]>
Date: Tue, 25 Nov 2008 14:11:29 -0800

Tolga,

It takes a capabilities exchange to determine who you (presumably) are 
communicating with and since SCTP streams parameters may be part of the 
peer definition, a predefined port won't allow this form of streams 
configuration. As far as I know the initial streams configuration cannot 
be renegotiated (correct me if I am wrong) within the same connection, 
so this would not allow per peer streams parameters.

Regards,
 Jan.

Asveren, Tolga wrote:
>> concern for handhelds or other devices with limited processing
>>     
> resources.
>   
>> "p2p start-TLS", i.e. item 2, with the addition of a secondary
>>     
> CER/CEA.
>   
>> Jan Nordqvist
>>>>> traffic is sent. Its the cleanest solution and would completely
>>>>>           
> secure
>   
>>>>> inband-security is set to TLS then it means the connecting peer
>>>>>           
> must
>   
>>>>> value. TLS setup will still be done after CER/CEA negotiation; the
>>>>>           
> way
>   
>>>>> its currently done. There will still be some backward
>>>>>           
> compatibility
>   
>>>>> Give the changes that's already been introduced in bis that
>>>>>           
> impacts
>   
>>>> In the meeting, we also spoke about a new "STARTTLS" command code
>>>>         
> which
>   
>>>> optionally comes before the CER which *might* be completely
>>>>         
> backwards
>   
>>>> compatible. I had the impression that this had some support in the
>>>>         
>> room.
>>     
>>>> What do you think?
>>>>
>>>>         
> reflect
>>> the existing vulnerability and that extensions are available to
>>>       
> help.
>

---

From: Jan Nordqvist <[email-masked]>
Date: Tue, 25 Nov 2008 14:14:01 -0800

I don't know or can think of any other way of doing TLS across multiple 
streams. Having a mixture of encrypted and non-encrypted streams seems 
like a less desirable set-up for me.

- Jan.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 25 Nov 2008 17:22:20 -0500

Jan,

Number of streams desired is negotiated during SCTP association
establishment in INIT/INIT-ACK chunks and for each direction the minimum
is used and I am also not aware of a way to renegotiate number of
streams.

I understand that there is a need to know what the initial advertised
value needs to be but I don't see why this needs to be per peer (an
argument of "because peer-X does not support negotiating stream values"
does not count IMHO. Peer-X needs to fix its SCTP implementation :-) ).

It *may* (actually I even doubt that) make sense that the initially
advertised value could be per target administrative domain but this is
known in advance.

Thanks,
Tolga

Of
> Jan Nordqvist
> Sent: Tuesday, November 25, 2008 5:11 PM
> To: [email-masked]
lets

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 25 Nov 2008 14:39:57 -0800

Jan Engelhardt [mailto://[email-masked]] writes:

...

> so that you can have mixed encryption/nonencryption in an

I have no idea why this would desirable.

...

---

From: "Thomas Lindgren" <[email-masked]>
Date: Wed, 26 Nov 2008 10:44:38 +0100

> Just to be clear, I prefer #1 as well.
I prefer #1 too.

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

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 26 Nov 2008 08:47:36 -0500

Hi Jan,

>
> The race condition occurs when two peers tries to connect to each 
> other at approximately the same time, i.e. before either side has 
> detected an incoming connection from the remote. This is obviously the 
> issue that the election process tries to deal with.

Sure. But for me this is independent of the security problem at hand 
.... anyway, I think most folks are in favor of option(1) and there 
should be no impact on existing election schemes regardless.

> CER/CEA, but at least in our implementation a secondary exchange would 

You may want to check the extensibility discussion regarding this.

-- victor

>>> If the initial CER/CEA handshake contains only minimal information 
>>> to get TLS going and another CER/CEA exchange is allowed to take 
>>> place inside the encrypted tunnel (which it used to be and likely 
>>> presents a minimal change to any existing implementation would it be 
>> Note that  folks have already agreed to remove CER/CEA exchange in 
>> the open state which poses a problem with the secondary CER/CEA.
>>
>>>> reflect the existing vulnerability and that extensions are 
>>>> available to help. Is this a good approach ?
>>>>
>>>> regards,
>>>> victor
>>>>
>>>>
>>>>> Stefan
>>>>>
>>>>>   
>>>>

---

From: Tom Taylor <[email-masked]>
Date: Wed, 26 Nov 2008 10:25:39 -0500

Add my vote for #1. Anything else seems to open up a bid-down attack.

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 26 Nov 2008 13:02:35 -0500

Hi,

> CER/CEA but it would have greater backward compatibility issues.

So far, more people are in favor of option (1) above. So if anybody has 
any new comments, objections, suggestions etc other than those already 
raised, pls speak up. Otherwise, we will move forward with the solution 
above.

regards,
victor

PS: Many thanks to all the folks who have contributed to the discussion
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Jan Engelhardt <[email-masked]>
Date: Wed, 26 Nov 2008 19:59:58 +0100 (CET)

On Wednesday 2008-11-26 19:02, Victor Fajardo wrote:
>>
>> 1. Define a new secured port for diameter used only for TLS. This deprecates
>> inband-security and moves TLS setup before any diameter traffic is sent. Its
>> the cleanest solution and would completely secure CER/CEA but it would have
>> greater backward compatibility issues.
>
> So far, more people are in favor of option (1) above. So if anybody has any new
> comments, objections, suggestions etc other than those already raised, pls
> speak up. Otherwise, we will move forward with the solution above.

I pick number 3 (starttls command).
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 26 Nov 2008 14:29:37 -0500

> I pick number 3 (starttls command).

that seems obvious already .... if there's nothing new we should move 
forward.

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 27 Nov 2008 12:08:50 +0900

Hello,
> So far, more people are in favor of option (1) above. So if anybody
> has any new comments, objections, suggestions etc other than those
> already raised, pls speak up. Otherwise, we will move forward with the
> solution above.
I just want to highlight the following fact for implementations:

In case option 1 (separate port for TLS) is selected, it will change the
validation of the credentials as described by 13.1. These credentials
can not be verified at the time of TLS handshake, but the connection
must be accepted, and the information saved until the CER/CEA is received.

I think this may open a possibility of DoS-type attacks, since the TLS
handshake is quite computational operation.

I would be more in favor of a splitting the CER/CEA exchange in two
messages. The first exchange would act as a STARTTLS command, by
identifying each peers (and eventually doing the Election). The second
exchange after the TLS is negotiated contains the remaining of the
current CER/CEA: supported applications, product information, ...

This allows to maintain a local configuration of what security mechanism
must be used with what peer (IPsec, TLS) and reject a non-TLS protected
connection with a peer for which the local configuration requires this
mechanism.

Any thoughts?

Thanks,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: Stefan Winter <[email-masked]>
Date: Thu, 27 Nov 2008 07:59:39 +0100

Hello,

> identifying each peers (and eventually doing the Election).

Identifying a peer can not be trusted in this unprotected CER, right?
So, for the sake of getting a TLS connection to the server (and
subsequently a DoS attack based on that) any host could send forged peer
IDs. So essentially, the same attack remains possible, regardless if a
split CER is used or a separate port.

>  The second

The second CER would need to repeat everything that was in the first CER
again since this one wasn't integrity-protected.

> connection with a peer for which the local configuration requires this

Wouldn't the same access restriction policy be achievable by using a
firewall towards the TLS-secured port of the Diameter peer?

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 27 Nov 2008 17:17:04 +0900

Hello,

> Identifying a peer can not be trusted in this unprotected CER, right?
Right, but...
> split CER is used or a separate port.
... it allows anyway to do some simple filtering (such as "no more than
3 attempts within X seconds from this Diameter ID, and reject all
unknown peers). Forging a DoS attack with such constaints becomes lot
more difficult.

> again since this one wasn't integrity-protected.
I agree, but the first message would basically contains only the
Origin-Host AVP and the (TBD) Start-TLS AVP, so its content will be
repeated in every subsequent message anyway...

> firewall towards the TLS-secured port of the Diameter peer?
Probably, yes. It means that when your Diameter topology changes, you
have to update not only the Diameter configuration, but also the
firewall configuration of your peers. IMHO it adds complexity to rely on
another component for security, but I agree it is a possible solution.

Best regards,
Sebastien.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 27 Nov 2008 13:18:44 -0800

> handshake is quite computational operation.

The problem with this conjecture is that the credential "verification" is
really no verification at all: the comparison is between a signed identity
from a PK cert and an unprotected assertion of identity.  I think that a DoS
attack mounted by modifying the unprotected identity is more likely than one
based upon the compute-intensity of the TLS handshake; if a peer doesn't
have enough computing power to handle the handshake w/o falling over it has
bigger problems ;-).

...

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 28 Nov 2008 04:35:19 -0500

Hi Sebastien,

> have enough computing power to handle the handshake w/o falling over it has

I would agree with Glen in this case. If option 1 is performed, 
validation in Sec 13.1 is no longer necessary since your doing mutual 
authentication via TLS certs already. If you allow the TLS handshake to 
succeed but somehow you don't trust the credentials in the certs you 
received (... which is strange to begin with) then you have a bigger 
security issues outside of Diameter and no amount of CER/CEA exchanges 
will help you with that.

regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 28 Nov 2008 04:51:35 -0500

Hi Sebastien,

> unknown peers). Forging a DoS attack with such constaints becomes lot

Do we really want to use Diameter protocol itself to prevent TLS DoS 
attacks ? This should be a general TLS/security issue that is 
independent of overlying protocol and that's why there's cryptographic 
work dedicated only to this issue. Otherwise its like forcing every 
other protocol that uses TLS to invent some sort of DoS prevention scheme.

-- victor

---

From: Mark Jones <[email-masked]>
Date: Fri, 28 Nov 2008 09:36:24 -0500

My vote goes to option 1 on this. Clean and straightforward as already stated. I'm not seeing the advantage of option 2 in terms of impact on existing implementations.

Regards
Mark

---

From: <[email-masked]>
Date: Fri, 28 Nov 2008 18:11:39 +0100

IMHO, based on the current discussion, saying that the backwards compatibility is not a big issue in that case, especially when we are specifying a RFC-bis, I consider "Option 1" as good and simple enough to be adopted. Option 2, option 2-bis or option 3 do not provide significant added-value compared to option 1 to be selected.

Regards,

Lionel

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de Mark Jones
> Envoyé : vendredi 28 novembre 2008 15:36
> À : [email-masked]
> Objet : Re: [Dime] Options for securing CER/CEA
> 
> My vote goes to option 1 on this. Clean and straightforward 
> as already stated. I'm not seeing the advantage of option 2 
> in terms of impact on existing implementations.
> 
> Regards
> Mark

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 01 Dec 2008 10:56:38 +0900

Hi,

Thank you for your answers. See my comment inline.

Victor Fajardo a écrit :
> authentication via TLS certs already. If you allow the TLS handshake
> to succeed but somehow you don't trust the credentials in the certs
> you received (... which is strange to begin with) then you have a
> bigger security issues outside of Diameter and no amount of CER/CEA
> exchanges will help you with that.
I understand the point now, thank you. I anyway wonder why this
validation was suggested ("SHOULD") in the previous specification, since
I think the same trust to TLS credentials already applied...

Best regards,
Sebastien.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 30 Nov 2008 20:41:39 -0800

> I think the same trust to TLS credentials already applied...

True, but then I can't believe that (apparently) nobody noticed until now
the problems with CER/CEA security 8-{.  Any way, it's not a bad idea,
although its actual purpose, I think, is authorization of the peer
connection rather than verification of credentials.  If only TLS supported
them, the same (or a better) job could be done with attribute certs...

...