Subject: [NSIS] TLS in the GIST draft

From: [email-masked]
Date: Thu, 13 Oct 2005 16:05:59 +0300

The current GIST draft has very little text about how TLS is actually
used with GIST. I think there are a couple of issues that need to be
handled somehow.

First, other protocols that have mandated the use of TLS have often
specified exactly what subset of TLS features must be supported.
For instance, RFC 3588 Section 13.2 says

   A Diameter node that initiates a connection to another Diameter
   node acts as a TLS client according to [TLS], and a Diameter node
   that accepts a connection acts as a TLS server.  Diameter nodes
   implementing TLS for security MUST mutually authenticate as part of
   TLS session establishment.  In order to ensure mutual
   authentication, the Diameter node acting as TLS server must request
   a certificate from the Diameter node acting as TLS client, and the
   Diameter node acting as TLS client MUST be prepared to supply a
   certificate on request.

   Diameter nodes MUST be able to negotiate the following TLS cipher
   suites:

      TLS_RSA_WITH_RC4_128_MD5
      TLS_RSA_WITH_RC4_128_SHA
      TLS_RSA_WITH_3DES_EDE_CBC_SHA

   Diameter nodes SHOULD be able to negotiate the following TLS cipher
   suite:

      TLS_RSA_WITH_AES_128_CBC_SHA

   Diameter nodes MAY negotiate other TLS cipher suites.

Something like this might be useful for the GIST draft as well, since
just saying "use TLS" is not sufficient to guarantee any kind of
interoperability.

Second, the Stack-Proposal negotiation seems to assume that a single bit

of information, that TLS is used, is sufficient to get TLS working.

This is not necessarily the case. Some TLS authentication mechanisms
assume the client (initiating the TLS connection) knows beforehand
either what credentials it wants to use itself, and/or what is
the expected identity of the server.

For instance, in Kerberos ciphersuites for TLS [RFC2712], the client
has to obtain a ticket from the KDC/TGS, and put it in the TLS
ClientKeyExchange message. But to obtain the ticket, the client has 
to know the server's PrincipalName -- where exactly does it get this
information?

(One option would be to send it in Stack-Configuration-Data.
Another would be to specify a way to derive it from other information 
that's already present in the messages, like Network-Layer-Information.
Perhaps there are other options too.)

To take another example, when using SRP to authenticate TLS
[draft-ietf-tls-srp-10], the client sends its SRP user name in the
ClientHello message. If the client has multiple secrets (SRP
password), it has to decide beforehand which of them to use.
Presumably, the identity of the TLS server is a major factor in 
this decision.

In fact, public-key certificates seem to be pretty much the only 
TLS case where no prior knowledge is required by the client (mainly
because the server sends its certificate first).

Best regards,
Pasi

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

---

From: [email-masked]
Date: Fri, 14 Oct 2005 10:11:17 +0300

Pasi,

Do you think that the Diameter text would be useful for GIST, or
do you have other suggestions on what is currently common practice for
TLS features?

For your second point, I agree with your analysis, but do you have
a suggestion on the best way to handle the TLS negotiation?

John

>The current GIST draft has very little text about how TLS is 
>actually used with GIST. I think there are a couple of issues 
>that need to be handled somehow.
>
>First, other protocols that have mandated the use of TLS have 
>often specified exactly what subset of TLS features must be supported.
>Something like this might be useful for the GIST draft as 
>well, since just saying "use TLS" is not sufficient to 
>guarantee any kind of interoperability.
>
>
>Second, the Stack-Proposal negotiation seems to assume that a 
>single bit of information, that TLS is used, is sufficient to get TLS
working.
>
>This is not necessarily the case. Some TLS authentication 
>mechanisms assume the client (initiating the TLS connection) 
>knows beforehand either what credentials it wants to use 
>itself, and/or what is the expected identity of the server.
>
>For instance, in Kerberos ciphersuites for TLS [RFC2712], the 
>client has to obtain a ticket from the KDC/TGS, and put it in 
>the TLS ClientKeyExchange message. But to obtain the ticket, 
>the client has to know the server's PrincipalName -- where 
>exactly does it get this information?
>
>Another would be to specify a way to derive it from other 
>information that's already present in the messages, like 
>Network-Layer-Information.
>[draft-ietf-tls-srp-10], the client sends its SRP user name in 
>the ClientHello message. If the client has multiple secrets 
>(SRP password), it has to decide beforehand which of them to use.
>Presumably, the identity of the TLS server is a major factor 
>in this decision.
>
>In fact, public-key certificates seem to be pretty much the 
>only TLS case where no prior knowledge is required by the 
>client (mainly because the server sends its certificate first).
>
>Best regards,
>Pasi
>

---

From: [email-masked]
Date: Fri, 14 Oct 2005 14:02:35 +0300

John Loughney wrote:
> do you have other suggestions on what is currently common practice 
> for TLS features?

This really depends on what is the goal of specifying the use of 
TLS in the GIST draft..

Something like the Diameter text is fine if the main goal is to
provide one plausible way to secure the GIST messaging (and pass
the security area review :-)  But between the lines you can
certainly read that "we wrote this just because we had to, not
because we think that this is the way NSIS+TLS will actually be
used in real deployments"...

But then again, writing correct text to cover all possible
real-world deployment scenarios is certainly quite impossible.
And for NSIS, probably we don't quite yet know how it will
be actually used and deployed..

> For your second point, I agree with your analysis, but do you 
> have a suggestion on the best way to handle the TLS negotiation?

The current text seems to cover the "TLS authenticated with
certificates" case reasonably well, so one option would be just
to say so, and explicitly say that Kerberos etc. are beyond the 
scope of this document. (If nobody plans to use Kerberos and 
RFC2712 with NSIS, spending a lot of effort to figure out how 
exactly it would work is probably not that great idea.)

Best regards,
Pasi

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 17 Oct 2005 23:54:50 +0100

hi pasi, john, all,

[warning: long, dense mail]

i've had time to think about this a little. in terms of what one
could specific about TLS, there seem to be 4 (related) issues,
all of one it would be good to see some more discussion on.

1. TLS version. The draft currently says MUST 1.0, SHOULD 1.1.
Given that GIST will be built from TLS libraries (rather than
already deployed TLS code), maybe we could be more prescriptive
about wanting 1.1; would that be a good or bad thing?

2. Cipher suites (raised earlier in this thread). AFAICT from
reading them, the TLS documents specify a single (mandatory
to implement) cipher suite, so TLS compliance is enough to 
provide interoperability from that point of view. Is there a
need to be more prescriptive here? (Why did Diameter do so?)

3. What authentication methods (certificates, EAP, SRP, etc. 
etc.) should be implemented. (Sometimes the authentication method
seems to be implied by offering a certain special ciphersuite,
as in the PSK case in particular.)

4. How to decide which identity is to be asserted and
authenticated (of querying and responding node).

(3) and (4) are the hard ones. However, AFAICT they are really
linked, in that if you can work out which identities you want
to deal with, that implicitly tells you what authentication
method needs to implemented to support it. So, for (3) I don't
think extra protocol machinery is required (there may be a 
case for different accompanying documentation, see the end).

So, the question is whether more work needs to be done on GIST
to at least leave open the possibility of doing something decent
for identity negotiation as per (4). If containers are needed
in the GIST handshake to do this I would like to get them 
identified at this stage, unless it turns into a real nightmare.

There are 3 places where identity information could be derived
from the GIST handshake:
a) in the NLI (possible in current spec)
b) as option data in the SCD (need to add a format for 
option data to the TLS higher layer information format)
c) as option data in the stack-proposal object (need to
change the object format, quite significantly).

The main reason for putting something in (c) is to be able
to validate that it has not been modified in the protocol
exchange (done by repeating it in the Confirm). But any decent
authentication protocol will provide that function internally.
So, it seems we don't need to do (c). Either of (a) or (b)
would be relatively trivial from a specification point of 
view.

What needs a bit more thought is how we expect authentication
to be configured in operational practice (in non-certificated
cases). Presumably, if a GIST node is going to authenticate
a peer, this means it has to know the identity of peers it
trusts enough to form MAs with, and know (or know how to 
retrieve) their credential information. So a GIST node will
have to have access to some identity database, of identities
of peers it will trust; this can also be used to configure the
node with which identity it uses for itself, and what 
authentication method to use. The requirement on the GIST
specification is then that it must exchange enough information
to allow lookups in this database. I think either of (a) or (b)
would be good enough for this purpose, provided the identities
exchanged are 'administratively' unique. There are some
advantages to using the NLI object for this purpose, since if
this changes it guarantees that a new MA is set up, whereas
if one relies on fields in the SCD, implementations have to
do a bit of extra work to trap this case.

Even if we do stick with the NLI, there may still be a need
to write something about operational issues. That could be
to encourage some uniformity in the selection of authentication
techniques, and also (maybe) proposing a structure for the
PI field in the NLI (if only to make it human-readable). 
That might be for the GIST spec itself, or (more likely?) 
for some separate BCP-like thing.

cheers,

robert h.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: 14 October 2005 12:03
> To: [email-masked]
> Subject: RE: [NSIS] TLS in the GIST draft
> 
> 
> John Loughney wrote:
> > Pasi,
> >