Subject: [NSIS] GIST authorisation

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 1 Mar 2007 09:42:23 -0000

hi all,

Several review comments on GIST related to the question of how a node
should decide to accept the creation of a secured messaging association
(specifically, how to decide that the TLS authentication step is
acceptable). A node can't just accept any authentication as acceptable,
because then the MA security would provide almost no value. (It would
prevent people disrupting the MA once established, but wouldn't prevent
anyone establishing it in the first place.) This is referred to as GIST
authorisation (note that it's got nothing to do with authorisation for
allocation of resources by the signalling application).

Conceptually what is required is an algorithm for the node, which takes
an identity and returns an 'OK/not OK' decision. That algorithm has to
use the identity along with some other dat; the simplest form of that
data is a list, and the algorithm is just a lookup. (You can imagine
other algorithms, such as invoking other protocols to check the
identity; however, these can all be modelled as different ways of
storing and accessing the list.) One needs to define criteria for when
an identity should be in the list, but that's about it.

Text based on the above description is in GIST -12 (currently with the
i-d editor). There are two aspects: the authorisation algorithm
described abstractly in terms of a list lookup, and TLS-specific details
about name matching in certificates. The abstract description is
attached below; it would be interesting to see if people see it as
under- or over-specification.

cheers,

r.

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

4.4.2.  GIST Peer Authorisation

   When two GIST nodes authenticate using a messaging association, both
   ends have to decide whether to accept the creation of the MA and
   whether to trust the information sent over it.  This can be seen as
   an authorisation decision:

   o  Authorised peers are trusted to install correct routing state
      about themselves and not, for example, to claim that they are on-
      path for a flow when they are not.

   o  Authorised peers are trusted to obey transport and application
      level flow control rules, and not to attempt to create overload
      situations.

   o  Authorised peers are trusted not to send erroneous or malicious
      error messages, for example asserting that routing state has been
      lost when it has not.

   This specification models the decision as verification by the
   authorising node of the peer's identity against a local list of
   peers, the authorised peer database (APD).  The APD is a abstract
   construct, similar to the security policy database of IPsec [39].
   Implementations MAY provide the associated functionality in any way
   they choose.  This section defines only the requirements for APD
   administration and the consequences of successfully validating a
   peer's identity against it.

   The APD consists of a list of entries.  Each entry includes an
   identity, the namespace from which the identity comes (e.g.  DNS
   domains), the scope within which the entry is applicable, and whether
   authorisation is allowed or denied.  The following are example
   scopes:

   Peer Address Ownership:  The scope is the IP address at which the
      peer for this MRI should be; the APD entry denotes the identity as
      the owner of address.  If the authorising node can determine this
      address from local information (such as its own routing tables),
      matching this entry shows that the peer is the correct on-path
      node and so should be authorised.  The determination is simple if
      the peer is one IP hop downstream, since the IP address can be
      derived from the router's forwarding tables.  If the peer is more
      than one hop away or is upstream, the determination is harder but
      may still be possible in some circumstances.  The authorising node
      may be able to determine a (small) set of possible peer addresses,
      and accept that any of these could be the correct peer.

   End-System Subnet:  The scope is an address range within which the
      MRI source or destination lie; the APD entry denotes the identity
      as potentially being on-path between the authorising node and that
      address range.  There may be different source and destination
      scopes, to account for asymmetric routing.

   The same identity may appear in multiple entries, and the order of
   entries in the APD is significant.  When a messaging association is
   authenticated and associated with an MRI, the authorising node scans
   the APD to find the first entry where the identity matches that
   presented by the peer, and where the scope information matches the
   circumstances for which the MA is being set up.  The identity
   matching process itself depends on the messaging association protocol
   that carries out the authentication, and details for TLS are given in
   Section 5.7.3.  Whenever the full set of possible peers for a
   specific scope is known, deny entries SHOULD be added for the
   wildcard identity to reject signalling associations from unknown
   nodes.  The ability of the authorising node to reject inappropriate
   MAs depends directly on the granularity of the APD and the precision
   of the scope matching process.

   If authorisation is allowed, the MA can be used as normal; otherwise
   it MUST be torn down without further GIST exchanges, and any routing
   state associated with the MA MUST also be deleted.  An error
   condition MAY be logged locally.  When an APD entry is modified or
   deleted, the node MUST re-validate existing MAs and the routing state
   table against the revised contents of the APD.  This may result in
   MAs being torn down or routing state entries being deleted.  These
   changes SHOULD be indicated to local signalling applications via the
   NetworkNotification API call (Appendix B.4).

   This specification does not define how the APD is populated.  As a
   minimum, an implementation MUST provide an administrative interface
   through which entries can be added, modified, or deleted.  More
   sophisticated mechanisms are possible in some scenarios.  For
   example, the fact that a node is legitimately associated with a
   specific IP address could be established by direct embedding of the
   IP address as a particular identity type in a certificate, or by a
   mapping that address to another identifier type via an additional
   database lookup (such as relating IP addresses in in-addr.arpa to
   domain names).  An enterprise network operator could generate a list
   of all the identities of its border nodes as authorised to be on the
   signalling path to external destinations, and this could be
   distributed to all hosts inside the network.  Regardless of the
   technique, it MUST be ensured that the source data justify the
   authorisation decisions listed at the start of this section, and that
   the security of the chain of operations on which the APD entry
   depends cannot be compromised.

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

---

From: Ali Fessi <[email-masked]>
Date: Thu, 01 Mar 2007 16:09:21 +0100

Hi Robert,

just my opinion: few comments are inline, otherwise I think it is fine.

Hancock, Robert wrote:
>    Section 5.7.3.  

Section 5.7.3 specifies the use of TLS with either server-only or mutual 
authentication. It's not clear to me, in which cases, the server-only 
authentication can be sufficient and in which cases, authentication of 
the client is additionally needed. It the "GIST peer"/"TLS client" is 
not authenticated in any way, then it won't be possible to take the 
authorization decisions for GIST listed above. I know it won't be always 
possible for the client to provide a certificate. But there might be a 
problem here.

>    Whenever the full set of possible peers for a
>    through which entries can be added, modified, or deleted.  

I think up to here, it is fine. The rest is probably not needed - at 
least in this document. It might be too early to think of how to 
populate GIST APDs in the network. But maybe in few years, we may think 
of a "GIST APD Propagation Protocol" ;-)

>    More

cheers,
  ali

-- 
Ali Fessi
Computer Networks and Internet
University of Tuebingen, Germany
Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220
EMail: [email-masked]
Web: http://net.informatik.uni-tuebingen.de/~fessi/

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 7 Mar 2007 10:16:09 -0000

hi ali,

thanks for the feedback. comments on the comments below: 

> -----Original Message-----
> From: Ali Fessi [mailto:[email-masked]] 
> Sent: 01 March 2007 15:09
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: Re: [NSIS] GIST authorisation
> 
> Hi Robert,
> 
> > should decide to accept the creation of a secured messaging 
> > association (specifically, how to decide that the TLS 
> authentication 
> > step is acceptable). A node can't just accept any authentication as 
> > acceptable, because then the MA security would provide almost no 
> > value. (It would prevent people disrupting the MA once established, 
> > but wouldn't prevent anyone establishing it in the first 
> place.) This 
> > is referred to as GIST authorisation (note that it's got 
> nothing to do 
> > with authorisation for allocation of resources by the 
> signalling application).
> > 
> > Conceptually what is required is an algorithm for the node, which 
> > takes an identity and returns an 'OK/not OK' decision. That 
> algorithm 
> > has to use the identity along with some other dat; the 
> simplest form 
> > of that data is a list, and the algorithm is just a lookup. 
> (You can 
> > imagine other algorithms, such as invoking other protocols to check 
> > the identity; however, these can all be modelled as 
> different ways of 
> > described abstractly in terms of a list lookup, and TLS-specific 
> > details about name matching in certificates. The abstract 
> description 
> > is attached below; it would be interesting to see if people 
> see it as
> Section 5.7.3 specifies the use of TLS with either 
> server-only or mutual authentication. It's not clear to me, 
> in which cases, the server-only authentication can be 
> sufficient and in which cases, authentication of the client 
> is additionally needed. It the "GIST peer"/"TLS client" is 
> not authenticated in any way, then it won't be possible to 
> take the authorization decisions for GIST listed above. I 
> know it won't be always possible for the client to provide a 
> certificate. But there might be a problem here.

i think we already say that channel security is mandatory to 
implement but optional to use. so the server only vs. client/server
authentication distinction is just a special case of this:
the server always asks for a client certificate, and if the server
policy is that it will not signal with unauthorised peers then
if the client doesn't provide a certificate, the whole step will
fail.

> I think up to here, it is fine. The rest is probably not 
> needed - at least in this document. It might be too early to 
> think of how to populate GIST APDs in the network. But maybe 
> in few years, we may think of a "GIST APD Propagation Protocol" ;-)

i half agree and half disagree. firstly, note that none of the text
below is normative for a GIST implementation - it's just supporting
background. the purpose is to show that, at least in some circumstances,
populating the APD semi-automatically is feasible. whether it is
worth showing that is maybe another question.

r.

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 7 Mar 2007 22:01:32 +0100

Hi Ali and Robert,

The proposed text looks fine for me and ...

> worth showing that is maybe another question.

I'm in favour of leaving the text as is, because it is a) informative  
only and b) some more text might be good for implementers. The  
implementers are probably thankful for some verbose text.

Thanks,

   Martin

[email-masked]
NEC Europe Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
Registered in England 2832014