Subject: RE: [NSIS] TLS in the GIST draft

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 14 Dec 2005 18:32:50 -0000

hi pasi, all,

after a certain amount of agonising about this issue, i
have the following proposal (proposed text at the end).

I believe that it is necessary to add text on mandatory ciphersuites. It
also
seems to be important in the long term to allow the more flexible uses
of TLS,
and that some of these require more information than just the TLS usage
selection in the first place. However, some of the options for TLS usage
are
currently somewhat speculative, and there is a case for implementing the
basic
certificate TLS usage first while leaving the way open for more advanced
uses.

The following text is proposed for section 5.7.3:

========================================================================
==

5.7.3.  Protocol Definition: Transport Layer Security

   This defines the use of transport layer security as a basic channel
   security mechanism.  Support for this protocol is mandatory;
   associations using it can carry messages with the transfer attribute
   Secure=True.  For use with TCP, implementation of TLS1.0 [6] is
   REQUIRED and implementation of TLS1.1 [8] is RECOMMENDED.  (If an
   unreliable transport such as DCCP or UDP is defined for GIST in the
   future, TLS would be implemented with it using DTLS [36].)  GIST
   nodes supporting TLS1.0 or TLS1.1 MUST be able to negotiate the
   following TLS ciphersuites:

   o  TLS_RSA_WITH_RC4_128_MD5

   o  TLS_RSA_WITH_RC4_128_SHA

   o  TLS_RSA_WITH_3DES_EDE_CBC_SHA

   and SHOULD be able to negotiate the following TLS ciphersuite:

   o  TLS_RSA_WITH_AES_128_CBC_SHA

   The default mode of TLS authentication (which applies in particular
   to the above ciphersuites) is server-only or mutual authentication
   using certificates.  The Querying node acts as a TLS client, and the
   Responding node acts as a TLS server.  Where one of the above
   ciphersuites is negotiated, the GIST node acting as a server MUST
   provide its own certificate, and MUST request one from the GIST node
   acting as a TLS client.

   GIST nodes MAY negotiate other TLS ciphersuites.  In some cases, the
   negotiation of alternative ciphersuites is used to trigger
   alternative authentication procedures (for example, the use of pre-
   shared keys).  Where the operation of the procedure depends on the
   prior knowledge of identity hints about the peer, these SHOULD be
   derived from the Peer-Identity provided in the NLI object of Query
   and Response messages.

   No higher-layer-addressing data is defined for TLS.

========================================================================
=

views?

robert h.

ps. in the tracker at
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue103

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 07 November 2005 21:22
> To: Hancock, Robert; [email-masked]
> Subject: RE: [NSIS] TLS in the GIST draft
> 
> 
> Robert Hancock wrote:
> 
> > 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?
> 
> Many existing TLS libraries don't support 1.1 yet, and since 
> the improvements in 1.1 are really minor, I don't see why we 
> should require it.
> 
> > 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?)
> 
> The mandatory-to-implement ciphersuite specified in RFC 2246 
> is TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. This can't be used in 
> many situations because it requires certificates containing 
> DSS public keys (most certs are RSA).
> 
> TLS 1.1 changes this to TLS_RSA_WITH_3DES_EDE_CBC_SHA, which 
> is slightly better. But IMHO it is still worthwhile to clarify 
> this explicitly in the NSIS specs, especially if we do not 
> mandate 1.1.
> 
> > 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.)
> 
> The ciphersuite does imply something about the 
> authentication, but not necessarily everything that's needed. 
> But if we copy the Diameter text, it pretty unambiguously 
> talks about mutual authentication using certificates.
> 
> > 4. How to decide which identity is to be asserted and authenticated 
> > (of querying and responding node
> >
> <snip>
> >
> > 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.
> 
> If it's required for actual interoperability, then it IMHO 
> needs to be in the GIST spec (or if it's a separate document, 
> the GIST spec will need a normative reference to it)... but I 
> guess it depends on the ambition level. It seems that for 
> certificates, this isn't really an issue, so copying the 
> Diameter text would be fine.
> 
> Best regards,
> Pasi
> 

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

---

From: [email-masked]
Date: Fri, 23 Dec 2005 11:46:29 +0200

Hi Robert,

A couple of comments:

- I don't think we need to make the RC4-based ciphersuites
mandatory; 3DES and AES will do just fine.

- Using TLS with server-only (Responding node only) authentication
sounds quite strange in this situation. To me it looks like
authenticating the querying node would be much more important...  
so the default mandatory-to-implement mechanism should do mutual
authentication.

- The requirement ".. identity hints about the peer, these SHOULD be
derived from the Peer-Identity provided..." is a bit strange.  

The spec says that the Peer-Identity is just an opaque octet string,
and nodes are free to choose it however they want, as long as it has
a "high probability of uniqueness". E.g. a sufficiently long and
properly generated random number would do. But clearly this text
assumes that Peer-Identity is something else than an opaque unique
string, since that would be quite useless in this case...

Also, to get interoperable implementations for e.g. using RFC2712
for GIST, it's not sufficient to say it's somehow derived from
Peer-Identity; some specification needs to say _how_ it's derived.

My recommendation would be to just define a MA-Protocol-ID 
for TLS-with-Certificates, and leave other kinds of TLS uses
beyond the scope of the specification (with the understanding
that they probably require a different MA-Protocol-ID).

Best regards,
Pasi 

> From: ext Hancock, Robert [mailto:[email-masked]] 
> Sent: 14 December, 2005 20:33
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> after a certain amount of agonising about this issue, i have the
> following proposal (proposed text at the end).
> 
> I believe that it is necessary to add text on mandatory
> ciphersuites. It also seems to be important in the long term to
> allow the more flexible uses of TLS, and that some of these
> require more information than just the TLS usage selection in the
> first place. However, some of the options for TLS usage are
> currently somewhat speculative, and there is a case for
> implementing the basic certificate TLS usage first while leaving
> the way open for more advanced uses.
> 
> ==============================================================
> ============
> 
>    This defines the use of transport layer security as a basic
>    channel security mechanism.  Support for this protocol is
>    mandatory; associations using it can carry messages with the
>    transfer attribute Secure=True.  For use with TCP,
>    implementation of TLS1.0 [6] is REQUIRED and implementation of
>    TLS1.1 [8] is RECOMMENDED.  (If an unreliable transport such as
>    DCCP or UDP is defined for GIST in the future, TLS would be
>    implemented with it using DTLS [36].)  GIST nodes supporting
>    TLS1.0 or TLS1.1 MUST be able to negotiate the following TLS
>    ciphersuites:
> 
>    The default mode of TLS authentication (which applies in
>    particular to the above ciphersuites) is server-only or mutual
>    authentication using certificates.  The Querying node acts as a
>    TLS client, and the Responding node acts as a TLS server.  Where
>    one of the above ciphersuites is negotiated, the GIST node acting
>    as a server MUST provide its own certificate, and MUST request one
>    from the GIST node acting as a TLS client.
> 
>    GIST nodes MAY negotiate other TLS ciphersuites.  In some
>    cases, the negotiation of alternative ciphersuites is used to
>    trigger alternative authentication procedures (for example, the
>    use of pre- shared keys).  Where the operation of the procedure
>    depends on the prior knowledge of identity hints about the
>    peer, these SHOULD be derived from the Peer-Identity provided
>    in the NLI object of Query and Response messages.
> 
> ==============================================================
> ============
> 
> views?
> 
> robert h.
> 
> ps. in the tracker at