Subject: FW: review/comments of/on draft-ietf-netconf-tls-00.txt

From: Charlie Kaufman <[email-masked]>
Date: Thu, 14 Feb 2008 11:23:00 -0800

I was reminded that I should copy this list with my additional comments below. I hope the formatting makes it through.

                --Charlie

From: Charlie Kaufman
Sent: Wednesday, February 13, 2008 11:22 PM
To: Badra
Cc: [email-masked]; Mohamad Badra
Subject: RE: review/comments of/on draft-ietf-netconf-tls-00.txt

Responses in brown prefixed [charliek:]  ... Charlie

From: Badra [mailto:[email-masked]]
Sent: Wednesday, February 13, 2008 5:13 PM
To: Charlie Kaufman
Cc: [email-masked]; Mohamad Badra
Subject: Re: review/comments of/on draft-ietf-netconf-tls-00.txt

Dear Charlie,

Thank you very much for your comments. Comments in-line:

Netconf requires that its transport provide mutual authentication of client and server, so cipher suites that are anonymous or which only authenticate the server to the client MUST NOT be used with Netconf. This document specifies how to use TLS with endpoint authentication in TLS can be based on either preshared keys [RFC4279] or public key certificates [RFC4246]. Some cipher suites (e.g. TLS_RSA_PSK_WITH_AES_128_CBC_SHA) use both. Section 3.1.1 describes how the client authenticates the server if public key certificates are provided by the server, section 3.1.2 describes how the server authenticates the client if public key certificates are provided by the client, and section 3.2 describes how the client and server mutually authenticate one another using a password.

It is a perfect text for me.
Just a samll comment, should I say something here about Kerberos or it is not required?
[charliek:] I don't think it's necessary unless you want to specify how you could use Netconf over TLS with Kerberos authentication. I suspect you don't want to deal with it.

[Thinking about it, I think it would be better to renumber section 3.1.1 as section 3.1, section 3.1.2 as 3.2, and section 3.2 as 3.3.]

Yes

The title of section 3.2 is slightly misleading, since authentication based on a password is actually mutual authentication. It might be better to shorten the title to "Password-Based Authentication".

OK

Section 4 requires implementation of three different crypto suites. Is that actually what you intended? I would think that either TLS_DHE_PSK_WITH_AES_128_CBC_SHA or TLS_RSA_PSK_WITH_AES_128_CBC_SHA would be the common case (I don't know which... do you?) and use of the other two would be rare.
In fact, I integrated the point 6 of your mail available at https://ops.ietf.org/lists/netconf/netconf.2008/msg00067.html

[charliek:] Oops... sorry. I was thinking that those three would be the most common, but if one of those three is more common than the others, having a single mandatory suite would be best of all.

- Section 9 of TLS V1.2 (http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4346-bis-09.txt) says that TLS_RSA_WITH_AES_128_CBC_SHA is mandatory.
- Section 9 of RFC4346 says that TLS_RSA_WITH_3DES_EDE_CBC_SHA is the mandatory cipher suite.

So I think it is better to don't recommend any certificate-based ciphersuite

You might want to make one of both of those mandatory and the others optional. You should probably say that any suite providing mutual authentication is optional.

But as section 3 already mentions that "cipher suites that are anonymous or which only authenticate the server to the client MUST NOT be used with Netconf". So I don't see think that we should repeat it here.

[charliek:] I was trying to make a different point. You already said that cipher suites that are anonymous or which only authenticate the server to the client MUST NOT be used, but what you could say is that any cipher suite that provides mutual authentication MAY be used.

3DES is widely used, and EDH provide PFS, so I would prefere TLS_DHE_PSK_WITH_AES_128_CBC_SHA.

What about:

4. Cipher Suite Requirements

A compliant implementation of this document MUST implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA.

[charliek:] How about:

[charliek:] A compliant implementation of the protocol specified in this document MUST implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA and MAY implement any TLS cipher suite the provides mutual authentication.

[charliek:] [Note: I don't feel strongly about any of this; it just seems like this is what you mean. My only worry about my wording is that it may raise the question of Kerberos again.]

Many thanks
Best regards,

Badra

From: Badra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, February 13, 2008 2:37 PM
To: Charlie Kaufman; [email-masked]<mailto:[email-masked]>

Subject: Re: review/comments of/on draft-ietf-netconf-tls-00.txt

Dear Charlie and Bert,

I would like to submit a new version of Netconf over TLS document before the cutoff. I updated it by including all the comments posted at the mailing list.

I attached the new version and a diff between the 00 and 01 versions.

Please feel free to give me your comments, especially regarding the password authentication.

Best regards,

Badra

--
Badra

---

From: Mohamad Badra <[email-masked]>
Date: Fri, 15 Feb 2008 11:11:40 +0100

Thank you Charlie.

I submitted a new version of the document that addresses the raised 
comments. Please don't hesitate to submit your comments. Many thanks!

Best regards,
Badra

Charlie Kaufman a écrit :
> I was reminded that I should copy this list with my additional comments 
> below. I hope the formatting makes it through.
> 
>  
> 
>                 --Charlie
> 
>  
> 
> *From:* Charlie Kaufman
> *Sent:* Wednesday, February 13, 2008 11:22 PM
> *To:* Badra
> *Cc:* [email-masked]; Mohamad Badra
> *Subject:* RE: review/comments of/on draft-ietf-netconf-tls-00.txt
> 
>  
> 
> Responses in brown*/ /*prefixed */[charliek:] /* … Charlie
> 
>  
> 
> *From:* Badra [mailto:[email-masked]]
> *Sent:* Wednesday, February 13, 2008 5:13 PM
> *To:* Charlie Kaufman
> *Cc:* [email-masked]; Mohamad Badra
> *Subject:* Re: review/comments of/on draft-ietf-netconf-tls-00.txt
> 
>  
> 
> Dear Charlie,
> 
>  
> 
>     Netconf requires that its transport provide mutual authentication of
>     client and server, so cipher suites that are anonymous or which only
>     authenticate the server to the client MUST NOT be used with Netconf.
>     This document specifies how to use TLS with endpoint authentication
>     in TLS can be based on either preshared keys [RFC4279] or public key
>     certificates [RFC4246]. Some cipher suites (e.g.
>     TLS_RSA_PSK_WITH_AES_128_CBC_SHA) use both. Section 3.1.1 describes
>     how the client authenticates the server if public key certificates
>     are provided by the server, section 3.1.2 describes how the server
>     authenticates the client if public key certificates are provided by
>     the client, and section 3.2 describes how the client and server
>     mutually authenticate one another using a password.
> 
>  
> 
>  
> 
> */[charliek:] /*I don’t think it’s necessary unless you want to specify 
> how you could use Netconf over TLS with Kerberos authentication. I 
> suspect you don’t want to deal with it.
> 
>      
> 
>     [Thinking about it, I think it would be better to renumber section
>     3.1.1 as section 3.1, section 3.1.2 as 3.2, and section 3.2 as 3.3.]
> 
>      
> 
> Yes
> 
>     The title of section 3.2 is slightly misleading, since
>     authentication based on a password is actually mutual
>     authentication. It might be better to shorten the title to
>     "Password-Based Authentication".
> 
>      
> 
> OK
> 
>     Section 4 requires implementation of three different crypto suites.
>     Is that actually what you intended? I would think that either
>     TLS_DHE_PSK_WITH_AES_128_CBC_SHA or TLS_RSA_PSK_WITH_AES_128_CBC_SHA
>     would be the common case (I don't know which… do you?) and use of
>     the other two would be rare.  
> 
> In fact, I integrated the point 6 of your mail available at 
> https://ops.ietf.org/lists/netconf/netconf.2008/msg00067.html
> 
>  
> 
> */[charliek:] /*Oops… sorry. I was thinking that those three would be 
> the most common, but if one of those three is more common than the 
> others, having a single mandatory suite would be best of all.
> 
>  
> 
> - Section 9 of TLS V1.2 
> (http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4346-bis-09.txt) 
> says that TLS_RSA_WITH_AES_128_CBC_SHA is mandatory.
> 
>     You might want to make one of both of those mandatory and the others
>     optional. You should probably say that any suite providing mutual
>     authentication is optional.
> 
>  
> 
> But as section 3 already mentions that "cipher suites that are anonymous 
> or which only authenticate the server to the client MUST NOT be used 
> with Netconf". So I don't see think that we should repeat it here.
> 
>  
> 
> */[charliek:] /*I was trying to make a different point. You already said 
> that cipher suites that are anonymous or which only authenticate the 
> server to the client MUST NOT be used, but what you could say is that 
> any cipher suite that provides mutual authentication MAY be used.
> 
>  
> 
> */[charliek:] /*How about:
> 
>  
> 
> */[charliek:] /*A compliant implementation of the protocol specified in 
> this document MUST implement the cipher suite 
> TLS_DHE_PSK_WITH_AES_128_CBC_SHA and MAY implement any TLS cipher suite 
> the provides mutual authentication.
> 
>  
> 
> */[charliek:] /*[Note: I don’t feel strongly about any of this; it just 
> seems like this is what you mean. My only worry about my wording is that 
> it may raise the question of Kerberos again.]
> 
> 
> Many thanks
> Best regards,
> 
> Badra
> 
>  
> 
>  
> 
>      
> 
>      
> 
>     *From:* Badra [mailto:[email-masked] <mailto:[email-masked]>]
>     *Sent:* Wednesday, February 13, 2008 2:37 PM
>     *To:* Charlie Kaufman; [email-masked]
>     <mailto:[email-masked]>
> 
> 
>     *Subject:* Re: review/comments of/on draft-ietf-netconf-tls-00.txt
> 
>      
> 
>     Dear Charlie and Bert,
> 
>      
> 
>     I would like to submit a new version of Netconf over TLS document
>     before the cutoff. I updated it by including all the comments posted
>     at the mailing list.
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Fri, 15 Feb 2008 11:48:22 +0100

Thanks Badra. My initial comments have been addressed.

All WG Members, pls review this new revision and comment
prefereably well BEFORE we have our meeting at IETF71.

Bert Wijnen 

> -----Oorspronkelijk bericht-----
> Van: [email-masked]
> [mailto:[email-masked]]Namens Mohamad Badra
> Verzonden: vrijdag 15 februari 2008 11:12
> Aan: Charlie Kaufman
> CC: [email-masked]
> Onderwerp: Re: FW: review/comments of/on draft-ietf-netconf-tls-00.txt
> 
> 
> Thank you Charlie.
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Feb 2008 09:36:32 +0100

Hi Bert & Mohamad,

I am not a radius expert, but I think you might have a radius problem.  
It would seem that either the identity & identity_hint discussed in the 
draft cannot be unique to a host OR the radius server must perform the 
transformations with appropriate identity & identity_hint  passed along 
with the string presented by the client.  Keeping in mind that OTPs 
should be supported, it seems likely that the radius server would have 
to do the support.

I see that RFC 4590 might be related work.  It could be possible to 
propose a radius extension along similar lines.  However, I am by no 
means a radius expert.  Kaushik is, and David Nelson is, so I've CC'd 
them.  While the extension itself might be out of scope for NETCONF and 
in fact might be more generally useful, not having such an extension 
leads us towards an SNMPv3 problem and a future ISMS analog.  I don't 
think you have to gate this draft on that work, but the mandate that you 
hash the password is what causes the problem.  SASL solves this with 
PLAIN, but some people complain that it is not bound well to TLS.

Also, here are a few additional comments:

In that Section 3.3 Note 1, if you're going to say something is NOT 
secure, you should bound that statement and preferably provide a reference.

In that same section, Note 2, and I realize this may be my poor reading 
of RFC 4279, I do not see how the form of the PSK resultant (ASCII or 
HEX) is specified.

Above that point, the following statement requires further elaboration 
and the term "random" does not sit well on its own.

> It is RECOMMENDED that implementations
>    that allow the administrator to manually configure the password also
>    provide functionality for generating a new random password, taking
>    [RFC4086] into account.
While it's good that you cited RFC 4086, I doubt that Don Eastlake would 
use the term "random", but perhaps "pseudo random".  All of this having 
been said, I believe you're a bit off the beaten path, and you could 
probably cut this text in its entirety.

HTH...

Eliot

---

From: Mohamad Badra <[email-masked]>
Date: Tue, 19 Feb 2008 12:13:39 +0100

Hi Eliot,

Thank you for the comments. Responses and comments in-line..

> PLAIN, but some people complain that it is not bound well to TLS.

I am not a RADIUS expert too, and any reply from Kaushik Narayan, David 
Nelson and others is welcome.

I agree on the fact that the document doesn't make use of all existing 
password databases features. It only gives a way to generate a PSK from 
a password for NETCONF operating over TLS. While NETCONF relies on the 
transport layer for the user authentication, we are forced to provide a 
profile for using password within TLS "without" modifying TLS (note that 
there are some expired IDs that propose using OTP and passwords within 
TLS, e.g., draft-linn-otp-tls).

Regarding the transformations, I guess the exact encoding with RADIUS is 
implementation dependent. But I think RADIUS recommends UTF-8, (doesn't 
it?). If then it will be OK for the document when relying on RFC4279 
(the PSK identity, identity hint, and password are converted to a 
character string, and then encoded to octets using UTF-8).

Regarding OTP and the other passwaord mechanisms, I can identify the 
following three options to move forward with the password authentication:

1. keep the proposed profile to derive a PSK from a password and store 
the PSK with the identity and the hint in the database.

2. use TLS for establishing a secure session with the server 
authentication and then implement a "RADIUS client" on the client (AVP 
attributes inside the established TLS session).

3. specify NETCONF over EAP (encapsulation) over TLS.

4. others?

Personally, I am for the 1st option.

> secure, you should bound that statement and preferably provide a reference.

OK, I will insert RFC 4306 as reference.

> of RFC 4279, I do not see how the form of the PSK resultant (ASCII or 

RFC4279 section 5.1 gives the form of that. If this is not clear in the 
draft, what about inserting the following at the beginning of note 2: 
"The PSK identity, identity hint, and password MUST be first converted 
to a character string, and then encoded to octets using UTF-8 [UTF8]."

> probably cut this text in its entirety.

I would prefer to keep RFC4086 as a reference and remove the 'random'.

> Eliot

Many thanks!
Best regards,
-- 
Mohamad Badra
CNRS - LIMOS Laboratory

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 19 Feb 2008 08:34:34 -0500

Thanks for forwarding this, Eliot.

I'll take a few days to read the draft and then send you my thoughts.

Regards,

Dave Nelson

> -----Original Message-----
> From: Eliot Lear [mailto:[email-masked]]
> Sent: Tuesday, February 19, 2008 3:37 AM
> To: Bert Wijnen - IETF
> Cc: Mohamad Badra; [email-masked]; Nelson, David; Kaushik Narayan
> Subject: Re: new revision: draft-ietf-netconf-tls-01.txt
> 
> Hi Bert & Mohamad,
>

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 19 Feb 2008 09:41:37 -0800

Will get back with my thoughts after having read the draft.

---

From: Kaushik Narayan <[email-masked]>
Date: Wed, 20 Feb 2008 11:51:07 -0800

Hi Eliot, Mohamad,

The password authentication mechanism defined in section 3.3 would be
problematic to support if the authentication needs to be done by a RADIUS
server for a couple of reasons

1. I am not a TLS expert but I presume that the TLS server would need to
possess the PSK; I don't think it would be appropriate for a RADIUS server
to provide a RADIUS client with keys derived (PSK) from the user's password
without authenticating the user.

2. In many cases the user's password might not even be available with the
RADIUS server, they might be stored in LDAP (there may be ways to acquire
the password using a LDAP getuserpassword instead of a bind) or token
servers (OTP).

Given that password based mechanisms with passwords stored in a central
database (RADIUS, LDAP, OTP) would probably be the most widely used
mechanisms for NetConf & the security issues in deriving the PSK from a
password that you have pointed out in the draft; I am wondering why you
wouldn't consider using SASL or alternatively perform user authentication
once the TLS tunnel has been established (similar to HTTP).

Regards,
 kaushik

---

From: Mohamad Badra <[email-masked]>
Date: Thu, 21 Feb 2008 13:27:22 +0100

Dear Kaushik,

Thank you for your review and for your comments.

First of all, I would like to clarify a point on the document as it is 
written by today: it is based on using a PSK derived from a password, on 
using a certificate, or on both of them. Consequently, its main 
objective isn't to enable any password exchange type inside TLS for the 
user authentication. This authentication is done using ant TLS 
ciphersuite that is able to ensure mutual authentication.

Regarding your 2nd point, I think that RADIUS or LDAP can be used within 
the document by simply collect the PSK and its identity as en entry in 
the database, or by collect the password with the PSK and its identity 
at the TLS server and leave this server reacts as a proxy.

Regarding your 1st point, it is possible for the server to authenticate 
the user using SASL or EAP. But IMO, SASL or EAP over TLS should provide 
crypto-binding and I don't think we have that today. However, if the WG 
think that using PSK derived from a password isn't sufficient and that 
an abstraction layer (SASL, EAP, etc.) is required to enable using OTP 
and other password types, so please let me know, like that we can insert 
such a layer between NETCONF and TLS.

Best regards,
Badra

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 25 Feb 2008 11:57:35 +0100

Dear David, Eliot, and all,

Thank you very much for your comments and feedbacks.

I totally agree that the intended use case for TLS PSK is "closed 
environments". I also agree that NETCONF over TLS should enable the use 
of existing AAA infrastructures. I am working on that!

I think there are at least two possible ways to send the user's 
credentials through the TLS session to the agent.

1- Using an abstraction layer (e.g., SASL PLAIN as Eliot/David/Kaushik 
proposed in their last mails) and a NETCONF capability. But I would like 
to know from Eliot (and others), how then the manager will distinguish 
between the case of TLS mutual authentication (no need for the user's 
credentials) and the case when only the agent is authenticated with TLS 
and hence the user's credentials are required.

2- Sending the user's credentials during the TLS establishment when the 
manager isn't authenticated by a certificate or a TLS-PSK. (Not 
specified yet! but available at 
http://www.ietf.org/internet-drafts/draft-badra-tls-password-ext-01.txt).

Comments and help are wellcome!

Best regards,
Badra

David B. Nelson a écrit :
> I'm obviously jumping into the middle of what appears to be an ongoing
> discussion of the NETCONF over TLS work.
> 
> Let me say that in the ISMS work, in which SNMP Transport Models and
> Transport Security Models are defined, the goal was to leverage existing AAA
> infrastructures.  One deployment barrier to SNMPv3 is that the configuration
> of PSKs on each managed entity makes administration difficult.  If the user
> base for NETCONF is anything like the user base for SNMP, you may eventually
> see the same objection.
> 
> Quoting from Section 1, Introduction, of RFC 4279:
> 
>       Second, pre-shared keys may be more convenient from a key
>       management point of view.  For instance, in closed environments
>       where the connections are mostly configured manually in advance,
>       it may be easier to configure a PSK than to use certificates.
>       Another case is when the parties already have a mechanism for
>       setting up a shared secret key, and that mechanism could be used
>       to "bootstrap" a key for authenticating a TLS connection.
> 
> The intended use case for TLS PKS authentication is "closed environments"
> where manual configuration of PSKs is reasonable.  This is similar to the
> model for SNMP / USM.
> 
> In the ISMS work, we have made allusions to the fact that having a
> centralized AAA database behind SNMP authentication has the benefit of
> allowing that database of user identity to be common among multiple
> purposes, including NETCONF.  In enterprises, the AAA database may in fact
> be a corporate "single sign-on" solution.  I think the potential for
> leveraging existing AAA infrastructures for use with NETCONF is something
> that users will eventually require.
> 
> In order to effectively use RADIUS or other AAA for authentication (and
> possibly for authorization), two properties need to apply:
> 
> (1) The only PSK (shared credential) that needs to be configured on the
> managed entity is the shared secret used between the AAA client and the AAA
> server.
> 
> (2) The form of user identity (e.g. username and password) that is required
> of the user to access the managed entity is one that can be used within the
> existing AAA authentication methods.
> 
> In order to accomplish (2) you can either restrict the form of credentials
> to the existing set for the AAA protocol, or you can extend the existing
> set.
> 
> While the current PSK authentication proposal for NETCONF over TLS is
> technically sound, it is similar in its scaling properties to the USM
> authentication mechanism for SNMPv3.  I think it therefore inherits the same
> deployment constraints. I believe this is what Eliot was talking about when
> he says "...not having such an extension leads us towards an SNMPv3 problem
> and a future ISMS analog".  
> 
> So, what are the existing RADIUS authentication mechanisms?
> 
> (1) Username and Password (e.g. PAP)
> (2) Username, Challenge and Digest (e.g. CHAP or MS-CHAP)
> (3) EAP (supposedly restricted to the network access use case)
> (4) HTTP Digest
> 
>>> While NETCONF relies
>>> on the transport layer for the user authentication, we are forced to
>>> provide a profile for using password within TLS "without" modifying
>>> TLS (note that there are some expired IDs that propose using OTP and
>>> passwords within TLS, e.g., draft-linn-otp-tls).
> 
> This is indeed a limitation.  In the ISMS work for SNMP, we chose SSH as a
> transport, rather than TLS, partly because network operators were already
> routinely using SSH.  Additionally, SSH integrates with Username and
> Password authentication (among other methods).
> 
>>> Regarding the transformations, I guess the exact encoding with RADIUS
>>> is implementation dependent. But I think RADIUS recommends UTF-8,
>>> (doesn't it?).
> 
> That's simply a mechanism for supporting I18N for human readable strings
> that are used in RADIUS.
> 
>>> If then it will be OK for the document when relying on
>>> RFC4279 (the PSK identity, identity hint, and password are converted
>>> to a character string, and then encoded to octets using UTF-8).
> 
> Well, you're still looking at adding a new authentication method, or at
> least defining a new profile for adapted use of an existing one, to support
> this form of credentials.  I haven't looked at the details; this may not be
> too onerous, from a protocol definition perspective.
> 
> The attractiveness of leveraging existing AAA infrastructure, however, is to
> leverage *existing* AAA infrastructure, rather that requiring deployment of
> an enhanced version.  This leads to the strategy of re-using one of the
> existing authentication methods, rather than inventing a new one.
> 
> Regards,
> 
> Dave Nelson

---

From: Mohamad Badra <[email-masked]>
Date: Tue, 26 Feb 2008 17:34:30 +0100

Dear all,

I think we front the issue of defining correctly a common mechanism to 
enable using an authentication function for the manager via third parties.

There are many ways to move forward with third party authentication. 
Below three of them, sorry for this long mail. Any advice is wellcome...

1- <request-login>:
-------------------

In the past (June 2007), we discussed on the mailing list of the 
authentication function via third parties, and I proposed using alike a 
JUNOS capability: <request-login>. The rules (sent by Phil Shafer 
https://ops.ietf.org/lists/netconf/netconf.2007/msg00244.html) to handle 
this were pretty simple:

- The <request-login> RPC could only be performed if the TLS doesn't 
provide mutual authentication (the manager isn't authenticated),
- No other RPCs could be performed if the manager isn't authenticated.

In the case of TLS without manager authentication, we must leave the 
<request-login> RPC as the only valid RPC (e.g., anything else is an error.)

This proposal received one objection from Andy Bierman 
https://ops.ietf.org/lists/netconf/netconf.2007/msg00252.html

2- A TLS Extension or an Abstraction layer:
-------------------------------------------

Consequently, I edited the document to enable mutual authentication at 
the TLS layer without considering the use case of third party (AAA for 
example). But some comments and recommendation posted to the mailing 
list said that it is "absolutely" required to enable third party 
authentication.

I would like to have the WG reactions before the meeting in order to 
work on:

2.a- extending TLS (if you have some minutes, please look at 
http://tools.ietf.org/id/draft-badra-tls-password-ext-01.txt). In this 
document, alike SASL PLAIN is proposed within TLS. IMO, this requires an 
action to be taken by the TLS WG.

Or

2.b- on using an abstraction layer over TLS such as SASL (with a framing 
protocol that NETCONF sits above is required).

Dave Nilson proposed the following message transition diagram and 
explained: When a connection request is initiated by the manager to the 
managed entity (agent), e.g. via NETCONF, the manager sends the user's 
credential to the agent, which calls into the local AAA client, which in 
turn contacts the AAA server (over the network).  The user's credentials 
are validated at the AAA server, which in turn responds to the AAA 
client with an accept or reject message (over the network).

But he has the following question: Do you think this kind of 
AAA-integration will work in what you are trying to accomplish with 
NETCONF over TLS?

I CCed Charlie and Hannes for more eventual help.

Manager                Agent--PAM--AAA Client                 AAA Server
   |                      |            |                         |
   |--------------------->|            |                         |
   | TLS session estab.   |            |                         |
   |                      |            |                         |
   |--------------------->|            |                         |
   | User credentials     |            |                         |
   |                      |----------->|                         |
   |                      | User cred. |                         |
   |                      |            |                         |
   |                      |            |------------------------>|
   |                      |            |       Access Request    |
   |                      |            |                         |
   |                      |            |<------------------------|
   |                      |            |       Access Accept     |
   |                      |            |                         |
   |                      |<-----------|                         |
   |                      | User is OK |                         |
   |                      |            |                         |
   |<-------------------->|            |                         |
   |  NETCONF Exchanges   |            |                         |

3-Update BEEP:
--------------

I don't know if people want to update BEEP. If then I think it is better 
to update BEEP with the TLS mutual authentication as described in the 
document "NETCONF over TLS". But here we should keep a TCP port for 
BEEP, and a second port which is required to use TLS alone (mutual 
authentication by TLS itself) and to distinguish between them.

Best regards,
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Feb 2008 20:41:48 +0100

On Tue, Feb 26, 2008 at 05:34:30PM +0100, Mohamad Badra wrote:

> There are many ways to move forward with third party authentication. Below 
> three of them, sorry for this long mail. Any advice is wellcome...

[...]

I only see two options here:

a) Extending NETCONF with an authentication mechanism that can hook into
   SASL (which would be something for NETCONF to work on)

b) Getting TLS enhanced that it can do client authentication with passwords
   and such things natively (which is clearly not NETCONFs business)

I guess the answer will be given by the security folks. I believe we
need to seek security area advise here.

/js

PS: My understanding is that BEEP does hook into SASL so I don't think
    BEEP is an issue here.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>