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

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 6 Jan 2006 12:00:20 -0000

hi pasi,

comments below. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 23 December 2005 09:46
> To: Hancock, Robert; [email-masked]
> Subject: RE: [NSIS] TLS in the GIST draft
> 
> 
> 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.

that's fine with me; i just copied it from diameter and have
no personal love for rc4 so i'll remove them unless anyone 
shouts (really really soon!)

> 
> - 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.

I think I agree with you, but am not sure what text change
would be needed here. If the nodes have proper TLS implementations,
then they will have the functionality to perform mutual 
authentication (and the requirement for the Responding node
to request a certificate means that the mutual authentication
procedure will at least be started). But that is not the same
as mandating that the Querying node has to have a certificate
to itself send, which would seem to be a deployment/policy 
matter.

Are you suggesting that the Querying node MUST NOT offer TLS
in the GIST capability exchange unless it has a certificate 
which would enable mutual authentication to take place?

> 
> - 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).

I think we can delete the sentence. (I think when I wrote it
that I was thinking only about selecting which key to use
when using PSK authentication. But having re-read 4279 I see
that at least similar hint-like information is available internally
from the TLS handshake, so there's no need to replicate it
at the GIST level. And handling kerberos or GBA architectures
seems to be intrinsically more complicated anyway.) So we can
just say that use of other TLS authentication methods may 
require additional specification of how they are embedded in
GIST. (This is a general problem of specification writing:
where spec A incorporates spec B in some sense, it is 
extremely hard to be precise in spec A about what class of 
extensions to spec B is allowed, especially where those 
extensions haven't been written yet. I'm not sure if there is
a good form of words to capture it.)

i've included a new version of 5.7.3 below:
=======================================================================
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 [37].)  GIST
   nodes supporting TLS1.0 or TLS1.1 MUST be able to negotiate the TLS
   ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD be able to
   negotiate the TLS ciphersuite 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, [26]).  The use of other authentication procedures may
   require additional specification work to define how they can be used
   as part of TLS within the GIST framework, and may or may not require
   the definition of additional MA-Protocol-IDs.

   No higher-layer-addressing data is defined for TLS.
=======================================================================
cheers,

r.
> Best regards,
> Pasi 

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