Subject: RE: [Nea] Newcomer comments on draft-ietf-nea-requirements-04

From: <[email-masked]>
Date: Wed, 12 Sep 2007 16:47:12 -0700

Hello Kaushik,

My please find my response inline.

[snipped]

> 
> 
> 
> >> 
> >> 
> >> 
> >> Page 35, Section 7.4 Requirement PT-2 In addition to mutual 
> >> authentication specified in PT-2, the PT protocol must also be 
> >> capable of supporting server side only authentication
> >> 
> >> as an alternative to mutual authentication.  Server side only 
> >> authentication is common practice today in SSL VPNs. With this in 
> >> mind, please
> >> 
> >> consider changing "mutual authentication" to "mutual and
> server side
> >> only authentication schemes".
> >> 
> >> 
> >> <Kaushik>
> >> 
> >> 
> >> The requirement is a MUST for mutual authentication between NEA 
> >> clients & NEA servers. The mutual authentication could be
> achieved as
> >> a result of two independent authentication transactions
> (with binding
> >> for certain PTs), for e.g. For password based credentials, the NEA 
> >> server will be authenticated while a secure channel is being 
> >> established (such as
> >> TLS) and NEA client will be subsequently authenticated within that 
> >> secure channel.
> >> 
> >> 
> >> </Kaushik>
> >> 
> > 
> > <Gary>
> > Understood on the multi-layer approach. However, this
> requirement is
> > beyond the scope of the PT protocol and I think a new common C-XX 
> > requirement is necessary that states the NEA Client and NEA Server 
> > must provide  a secure channel via mutual authentication, 
> > confidentiality and integrity through one or more of the
> PA, PB and PT
> > protocols collectively.
> > As to my comment on PT-2, I believe that still stands as it is 
> > required for many if not most SSL VPN TLS connections.
> > </Gary>
> > 
> 
> <Kaushik-Response>
> 
> The common requirement would be redundant because we already have 
> individual requirements in PA, PB and PT for authentication, integrity

> & privacy protection. The reason for individual requirements is 
> because priority for the PA, PB and PT layer requirements are 
> different.
> 
> 
> Re-wording PT-2 to change "mutual authentication" to "mutual and 
> server side only authentication schemes" would mean that it would 
> acceptable have server-only authentication for PT which does not seem 
> sufficient.
> 
> 
> </Kaushik-Response>
> 
> 

<Gary>
My only concern is not explicitly stating the common requirement in the
normative section 7, but rather in the teachings of the non normative
section 8.2. If the WG is comfortable with that, then I'll concur.  

As to mutual authentication being necessary at the PT layer, I don't
concur at all as it isn't necessary if there is mutual authentication
being provided by an upper layer. For PT's such as 802.1X or IKE, PT
mutual authentication support is a given and thus PB and PA can rely on
it. However, for other
PT protocols, such as TLS it isn't a given at all. In fact, with TLS it
is unlikely mutual authentication will be employed in most remote access
use cases due to the lack of client cert adoption.  This is why I
recommended the changes in order to utilize PT simply for
confidentiality and rely on an upper protocol for authentication and
integrity.  An example might help here: In our SSL VPN solution as is
the case with other SSL VPN solutions I'm aware of, server side only
authentication is employed and the PB equivalent protocol provides
cryptographic mutual authentication between the PB handlers for trust
and integrity.  In this case, the PT protocol (i.e. TLS) is relied upon
for confidentiality.
</Gary>

[snippet]

> >> 
> >> <Kaushik>
> >> 
> >> Just want to point out that all the models described in section 9 
> >> are implementation considerations and not requirements for NEA 
> >> protocol specification. The models explain how NEA implementations 
> >> can address privacy concerns and it is upto to implementations to 
> >> support one or more of these models.
> >> 
> >> regards,
> >>  kaushik!
> >> 
> >> </Kaushik>
> >> 
> >> 
> > 
> > <Gary>
> > Understood, although I don't think section 9.2 paragraph 1 clearly 
> > states this.  I suggest rephrasing this paragraph to
> explicitly state
> > the NEA reference architecture and its protocols can be
> used with any
> > and
> > all of the 3 NEA Client to NEA Server interaction models;
> and that the
> > selection of an interaction model by a PC/PV implementer is use case

> > dependent. Once this context is established, I think it is fine to 
> > switch the context to protocol consideration guidance for the
> forthcoming PB
> > and
> > PA design teams.
> > 
> 
> 
> <Kaushik-Response>
> 
> The second sentence in Section 9 states
> 
> " This section will discuss a few of the potential privacy concerns 
> raised by the deployment of this technology and offer some guidance to

> implementers."
> 
> Does that seem adequate or do you think we need additional text in 
> section
> 9.2
> 
> 
> regards,
>  kaushik
> 
> </Kaushik-Response>
> 
> 

<Gary>
This part of the text is fine.  The part that through me for a loop is
"... whether a preferred approach will emerge potentially impacting the
protocols ...". I think we should plan to satisfy the three models in
the protocol work.  I'm comfortable with the verbiage now that I
understand the context better.

Regards,
Gary

</Gary>

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

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 13 Sep 2007 15:00:15 -0700

Hi Gary,

Please find my reply inline.

<snipped>

<Kaushik-Response>

I am still not sure how the common requirement won't be redundant if we have
individual requirements for PA, PB & PT (all of these are in Section 7). The
common requirements essentially apply to these three protocols.

</Kaushik-Response>

<Kaushik-Response>

I am not sure that client-side authentication would be limited to
certificates with TLS as transport. There are options for TLS to
authenticate using Kerberos (RFC2717), pre-shared keys (RFC4279)
& username/passwords (draft-ietf-tls-srp-14.txt). TLS should be able to meet
the mutual authentication requirements.

I think this discussion points out that we probably missing a table as part
of the PT requirements that indicates the type of client/server
authentication methods the PT is required to support.

regards,
 kaushik

</Kaushik-Response>