Subject: Re: [Nea] Comment re PT-TLS and SASL mechanism negotiation

From: Paul Sangster <[email-masked]>
Date: Mon, 12 Dec 2011 16:54:50 -0800

Susan,

Comments and proposed remedies are discussed below...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Susan Thomson
> Sent: Monday, November 14, 2011 4:51 PM
> To: [email-masked]
> Subject: [Nea] Comment re PT-TLS and SASL mechanism negotiation
> 
> I have a comment on PT-TLS I-D and SASL mechanism negotiation.
> 
> Re Sections 3.4.2.2. and 3.8.3:
> 
> The text is unclear as to whether the PTC or the PTS starts the 
> negotiation, leaving the possibility (if not the probability) that in 
> a particular implementation neither side initiates the exchange (or 
> both).

[PS:] In section 3.4.2.2, the first sentence says:

"Once a TLS session has been established between Posture Transport Client and Posture Transport Server, the PT-TLS Initiator sends a Version Request Message indicating it is supported PT-TLS protocol version range." 

Because either side may have initiated the TLS Setup Phase (e.g. NEA Client or Server could have triggered the TLS session), we use the term "PT-TLS Initiator".   This means who ever initiated the PT-TLS session goes first for version negotiation (not a race condition).

However for section 3.8.3 (SASL authentication), the -01 draft allows either party to initiate without a deadlock.  However this does introduce complexity so unless a use case for either side initiating the client (currently "entity") authentication then we will modify section 3.8 to just have the PTS initiate the client authentication and do away with the "entity" term which could be causing vagueness.   We will also be able to do away with the PT-TLS Initiator/Responder terminology as well if it's always the PTS that triggers the client authentication.

> 
> In the common use case where the server has the policy requiring a 
> client to authenticate, it must send a SASL mechanism message (unless 
> the client is required to initiate the exchange, which is not what the 
> spec currently says).
> 
> It might be good to first list out the common use cases we need to 
> support and the desired behavior, and then make sure that the draft 
> reflects that.

[PS:] Hopefully we don't need to repeat the use cases from RFC 5209 (as we didn't for PA and PB) but rather ensure that none of those require either side to trigger the client authentication.  I'm not aware of a use case that would require the PTC to trigger the client authentication but we'll look into it more.

> Right now, the draft supports all possible options, and it is not 
> always clear what is expected to happen in any particular scenario. It 
> also may be the case that the cost of supporting all these use cases 
> outweighs the benefit - the more use cases we have, the more testing 
> needs to be done, and the potential for interoperability issues rises. 
> But before we reach this conclusion, it would be good to first clarify 
> what use cases we think we need to support.

[PS:] Agreed

---

From: Susan Thomson <[email-masked]>
Date: Wed, 21 Dec 2011 10:24:45 -0500

Hi Paul

Thanks for the response.

Inline ... 

On 12/12/11 7:54 PM, "Paul Sangster" <[email-masked]> wrote:

> "Once a TLS session has been established between Posture Transport Client and
> Posture Transport Server, the PT-TLS Initiator sends a Version Request Message
> indicating it is supported PT-TLS protocol version range."
> 
> Because either side may have initiated the TLS Setup Phase (e.g. NEA Client or
> Server could have triggered the TLS session), we use the term "PT-TLS
> Initiator".   This means who ever initiated the PT-TLS session goes first for
> version negotiation (not a race condition).
> 
> However for section 3.8.3 (SASL authentication), the -01 draft allows either
> party to initiate without a deadlock.  However this does introduce complexity
> so unless a use case for either side initiating the client (currently
> "entity") authentication then we will modify section 3.8 to just have the PTS
> initiate the client authentication and do away with the "entity" term which
> could be causing vagueness.   We will also be able to do away with the PT-TLS
> Initiator/Responder terminology as well if it's always the PTS that triggers
> the client authentication.
> 

[ST] Agree that the text will become simpler to specify with just having the
PTS initiate.

> [PS:] Hopefully we don't need to repeat the use cases from RFC 5209 (as we
> didn't for PA and PB) but rather ensure that none of those require either side
> to trigger the client authentication.  I'm not aware of a use case that would
> require the PTC to trigger the client authentication but we'll look into it
> more.
> 
[ST] Your last sentence seemed to be the sentiment of the WG at the last
IETF meeting as well. We would just need to be sure that whatever we specify
is sufficient for addressing the use case in both directions (assuming we
continue to support SASL authn in both directions), i.e when NEA server is
playing role of PTS server and when NEA client plays that role.

Thanks
Susan