Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Tue, 3 Jun 2008 10:41:51 +0200

Juergen,

I agree, none of the options is satisfying and we should
be carefull with the wording in the document.

OTOH I can live with option #5 if pwd authentication 
and the usage of SSH is OPTIONAL. Would this be 
acceptable for you?

Cheers, 
Mehmet

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Juergen 
> Schoenwaelder
> Sent: Tuesday, May 27, 2008 2:42 PM
> To: Mohamad Badra
> Cc: [email-masked]
> Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4,5 
> for Enabling Third Party Authentication using Passwords
> 
> On Tue, May 27, 2008 at 02:16:21PM +0200, Mohamad Badra wrote:
>  
> > We would encourage any conFrom [email-masked]  Tue Jun  3 01:42:10 2008
Content-class: urn:content-classes:message
Date: Tue, 3 Jun 2008 10:41:51 +0200
From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4,
	5 for Enabling	Third Party Authentication using Passwords
Sender: [email-masked]

Juergen,

I agree, none of the options is satisfying and we should
be carefull with the wording in the document.

OTOH I can live with option #5 if pwd authentication 
and the usage of SSH is OPTIONAL. Would this be 
acceptable for you?

Cheers, 
Mehmet

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Juergen 
> Schoenwaelder
> Sent: Tuesday, May 27, 2008 2:42 PM
> To: Mohamad Badra
> Cc: [email-masked]
> Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4,5 
> for Enabling Third Party Authentication using Passwords
> 
> On Tue, May 27, 2008 at 02:16:21PM +0200, Mohamad Badra wrote:
>  
> > We would encourage any contribution that could be used in 
> combination 
> > with existing user authentication databases. Please don't 
> hesitate to 
> > submit your comments on the options described through 
> "NETCONF over TLS" 
> >   [1] document in Appendix B, or to post your proposal on 
> the mailing 
> > list to try to reach WG consensus.
> 
> My $.02 worth of comments:
> 
> : 1. Defining <user-login> RPC:
> 
> I share that the doubt that this will fly. Plain password
> authentication is just one out of many authentication methods out
> there.
> 
> : 2. Enhancing TLS:
> 
> Does not belong into the WG.
> 
> : 3. Running BEEP over TLS
> 
> This is already defined as part of the BEEP transport mapping.
> 
> : 4. Extending NETCONF with a message to start TLS
> 
> Extending NETCONF with a SASL hook is an architecture violation. But
> this does not preclude the option that the TLS transport for NETCONF
> does provide hooks for SASL.
> 
> : 5. Enable SSH (RFC4742 and TLS (as defined through this document:
> 
> This does not make any sense to me.
> 
> My suggestion is to actually do nothing to enable 3rd party
> authentication using passwords in this document other then wording
> things carefully such that something like this can be added in the
> future should this need ever arise.
> 
> /js
> 
> -- 
> 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/>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
> 
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

tribution that could be used in 
> combination 
> > with existing user authentication databases. Please don't 
> hesitate to 
> > submit your comments on the options described through 
> "NETCONF over TLS" 
> >   [1] document in Appendix B, or to post your proposal on 
> the mailing 
> > list to try to reach WG consensus.
> 
> My $.02 worth of comments:
> 
> : 1. Defining <user-login> RPC:
> 
> I share that the doubt that this will fly. Plain password
> authentication is just one out of many authentication methods out
> there.
> 
> : 2. Enhancing TLS:
> 
> Does not belong into the WG.
> 
> : 3. Running BEEP over TLS
> 
> This is already defined as part of the BEEP transport mapping.
> 
> : 4. Extending NETCONF with a message to start TLS
> 
> Extending NETCONF with a SASL hook is an architecture violation. But
> this does not preclude the option that the TLS transport for NETCONF
> does provide hooks for SASL.
> 
> : 5. Enable SSH (RFC4742 and TLS (as defined through this document:
> 
> This does not make any sense to me.
> 
> My suggestion is to actually do nothing to enable 3rd party
> authentication using passwords in this document other then wording
> things carefully such that something like this can be added in the
> future should this need ever arise.
> 
> /js
> 
> -- 
> 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/>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
> 
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Jun 2008 13:22:16 +0200

On Tue, Jun 03, 2008 at 10:41:51AM +0200, Ersue, Mehmet (NSN - DE/Muenich) wrote:
 
> OTOH I can live with option #5 if pwd authentication and the usage
> of SSH is OPTIONAL. Would this be acceptable for you?

I do not understand option #5 nor do I understand your statement since
the SSH transport is the mandatory to implement transport for NETCONF
(as per section 2.4 of RFC 4741).

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Jun 2008 13:22:16 +0200

/js

---

From: [email-masked]
Date: Tue, 3 Jun 2008 13:57:21 +0200 (CEST)

> (as per section 2.4 of RFC 4741).

Option #5 means that if the manager doesn't implement TLS with certificate
or psk-based authentication (the manager or the user wishes to use ala
unix password), the manager and the agent can rely on SSH to authenticate
the manager according to local policy before password-based
authentication. This resort is possible since SSH is mandtory within
Netconf.

Best regards,

---

From: [email-masked]
Date: Tue, 3 Jun 2008 13:57:21 +0200 (CEST)

Best regards,

---

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Tue, 3 Jun 2008 14:27:19 +0200

Hi Juergen,

> (as per section 2.4 of RFC 4741).

SSH transport is mandatory to implement but use of SSH-based 
password authentication in case of Netconf over TLS is not.
Using 'SSH for password authentication' and 'TLS for endpoint 
authentication with PSK or certificates' in combination can be 
introduced as OPTIONAL.

People who want to have this kind of access security can do 
what Badra describes. It would be worded as MAY or OPTIONAL 
in the TLS draft. 
Namely, the agent MAY passively listen for the incoming SSH 
(respectively TLS) connection on port 830 (respectively port 
<TBA-by-IANA>).

Cheers, 
Mehmet 

> From: ext Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, June 03, 2008 1:22 PM
> To: Ersue, Mehmet (NSN - DE/Muenich)
> Cc: [email-masked]; Mohamad Badra
> for EnablingThird Party Authentication using Passwords
>

---

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Tue, 3 Jun 2008 14:27:19 +0200

Hi Juergen,

Cheers, 
Mehmet

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Jun 2008 15:03:31 +0200

On Tue, Jun 03, 2008 at 02:27:19PM +0200, Ersue, Mehmet (NSN - DE/Muenich) wrote:
 
> Namely, the From [email-masked]  Tue Jun  3 06:07:19 2008
Date: Tue, 3 Jun 2008 15:03:31 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>,
	[email-masked], Mohamad Badra <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4,
	5 for	EnablingThird Party Authentication using Passwords
Reply-To: [email-masked]
Sender: [email-masked]

On Tue, Jun 03, 2008 at 02:27:19PM +0200, Ersue, Mehmet (NSN - DE/Muenich) wrote:
 
> Namelyagent MAY passively listen for the incoming SSH 

My problem is that I read the words, but I do not get the meaning.

- What has SSH password authentication to do with TLS??
- Isn't it obvious that I can use SSH?
- What is the purpose of MAY or OPTIONAL in this context? The choice
  of which authentication mechanism I use is a deployment decision not
  an implementation requirement...
- I don't get the port number sentence; is the idea here that both
  the SSH and the TLS transport share a listening endpoint? I wonder
  how people should implement this.

/js

, the agent MAY passively listen for the incoming SSH 
> (respectively TLS) connection on port 830 (respectively port 

My problem is that I read the words, but I do not get the meaning.

- What has SSH password authentication to do with TLS??
- Isn't it obvious that I can use SSH?
- What is the purpose of MAY or OPTIONAL in this context? The choice
  of which authentication mechanism I use is a deployment decision not
  an implementation requirement...
- I don't get the port number sentence; is the idea here that both
  the SSH and the TLS transport share a listening endpoint? I wonder
  how people should implement this.

/js

---

From: [email-masked]
Date: Tue, 3 Jun 2008 15:55:29 +0200 (CEST)

Dear Juergen,

> - What has SSH password authentication to do with TLS??

Nothing. But since TLS don't support a standFrom [email-masked]  Tue Jun  3 06:58:12 2008
Date: Tue, 3 Jun 2008 15:55:29 +0200 (CEST)
From: [email-masked]
To: [email-masked]
Importance: Normal
Cc: Ersue=?utf-8?Q?=2C=C2_Mehmet=C2_?=@core3.amsl.com,
	=?utf-8?Q?=C2?= <[email-masked]>
Subject: [Netconf] =?utf-8?b?IFJlOsKgwqBXR8KgQ29uc2Vuc3VzwqBvbsKgb3B0aW9u?=
 =?utf-8?b?c8KgMSzCoDIswqAzLMKgNCw1wqBmb3JFbmFibGluZ1RoaXJkwqBQYXJ0ecKg?=
 =?utf-8?q?Authentication=C2=A0using=C2=A0Passwords?=
Sender: [email-masked]

Dear Juergen,

> - What has SSH password authentication to do with TLS??

Nothing. But since TLS don't support a standard paard password-based
authentication (RFC 5054 specifies that but it is informational), so
managers that don't have certificates or PSK shared with the agent can
rely on SSH to establish password-based authentication. Please look at is
as you have SSH and BEEP or SOAP. They are independant and provide
security services each one by its own way.

> - Isn't it obvious that I can use SSH?

You can do that. And each of them has its advantages and drawbacks.

>   an implementation requirement...

Yes, but this would help implentors when decision is made.

>   how people should implement this.

The point is that the agent is configured *by default* to accept SSH
session, which provides, among others, ala unix authentication. But the
agent can also passively listen on a port specific to TLS to authenticate
the manager using certificate or psk derived from a password. So I don't
see where is the problem of implementing that.

Best regards,
Badra

ssword-based
authentication (RFC 5054 specifies that but it is informational), so
managers that don't have certificates or PSK shared with the agent can
rely on SSH to establish password-based authentication. Please look at is
as you have SSH and BEEP or SOAP. They are independant and provide
security services each one by its own way.

> - Isn't it obvious that I can use SSH?

You can do that. And each of them has its advantages and drawbacks.

>   an implementation requirement...

Yes, but this would help implentors when decision is made.

>   how people should implement this.

The point is that the agent is configured *by default* to accept SSH
session, which provides, among others, ala unix authentication. But the
agent can also passively listen on a port specific to TLS to authenticate
the manager using certificate or psk derived from a password. So I don't
see where is the problem of implementing that.

Best regards,
Badra

---

From: Phil Shafer <[email-masked]>
Date: Tue, 03 Jun 2008 10:19:51 -0400

FWIW I'm confused also.  I can't figure out if you are saying:

(a) TLS should use the same mechanism that SSH uses
(b) TLS doesn't need security, since you could use SSH if you wanted that
(c) TLS should generate certs based on SSH credentials
(d) TLS has already solved this issue

In particular, this paragraph is completely confusing:

>Nothing. But since TLS don't support a standard password-based

How can a manager using TLS rely on SSH?  You say they are independent
but that one can rely on the other.  This is not like From [email-masked]  Tue Jun  3 07:23:36 2008
To: [email-masked]
Date: Tue, 03 Jun 2008 10:19:51 -0400
From: Phil Shafer <[email-masked]>
Cc: Ersue=?utf-8?Q?=2C=C2_Mehmet=C2_?=@core3.amsl.com,
	=?utf-8?Q?=C2?= <[email-masked]>
Subject: Re: [Netconf]
	=?utf-8?b?wqDCoFdHwqBDb25zZW5zdXPCoG9uwqBvcHRpb25zwqAx?=
	=?utf-8?b?LMKgMizCoDMswqA0LDXCoGZvckVuYWJsaW5nVGhpcmTCoFBhcnR5wqBB?=
	=?utf-8?q?uthentication=C2=A0using=C2=A0Passwords?=
Sender: [email-masked]

FWIW I'm confused also.  I can't figure out if you are saying:

(a) TLS should use the same mechanism that SSH uses
(b) TLS doesn't need security, since you could use SSH if you wanted that
(c) TLS should generate certs based on SSH credentials
(d) TLS has already solved this issue

In particular, this paragraph is completely confusing:

>Nothing. But since TLS don't support a standard password-based

How can a manager using TLS rely on SSH?  You say they are independent
but that one can rely on the other.  This is not like BEEP oBEEP or SOAP,
which have their own authenitcation schemes.

Not to be a pain, but can you give a more detailed description of
how this works?

Thanks,
 Phil

[email-masked] writes:
>Nothing. But since TLS don't support a standard password-based

r SOAP,
which have their own authenitcation schemes.

Not to be a pain, but can you give a more detailed description of
how this works?

Thanks,
 Phil

[email-masked] writes:
>Nothing. But since TLS don't support a standard password-based

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Jun 2008 17:29:17 +0200

> see where is the problem of implementing that.

The TLS document needs to describe in detail how the TLS transport for
NETCONF works and it should IMHO avoid saying anything about the other
transports at all. RFC 4741 is pretty clear that SSH is the mandatory
to implement transport and I trust operators that they will manage to
figure out which of the NETCONF transports or combinations thereof
make sense for their environments.

So I am back to my preference: do nothing concerning passwords in the
TLS transport document.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Jun 2008 17:29:17 +0200

/js

---

From: [email-masked]
Date: Tue, 3 Jun 2008 17:41:13 +0200 (CEST)

> but that one can rely on the other.  This is not like BEEP or SOAP,

Dear Phil,

TLS defines its *own* authentication mechanism and key establishment.
It is not depend on SSH at all. TLS use certificates and public keys, or
pre-shared keys + psk's identifiers, independately of SSH or any other
security protocol.

What I am trying to say is the following:

In case the manager wishes to authenticate itself to the agent using
certificates and/or preshared keys derived from paswords, both the manager
and the agent can implement TLS over Netconf (only TLS).

In case the manager don't process a certificate or a psk, the manager can
authenticate itself using SSH (only SSH).
Best regards,
Badra

---

From: [email-masked]
Date: Tue, 3 Jun 2008 17:41:13 +0200 (CEST)

Dear Phil,

---

From: [email-masked]
Date: Tue, 3 Jun 2008 17:55:26 +0200 (CEST)

Dear Juergen,

> make sense for their environments.

Well, the only thing that TLS document brings from RFC4742 is tha a
special character sequence ]]>]]>

   Current NETCONF messages don't include a message's length.  This
   document uses consequently the same delimiter sequence defined in
   [RFC4742] and therefore the special character sequence, ]]>]]>, to
   delimit XML documents.

I think a simple reference to RFC4742 is bettre than duplicating the text
related to this special character sequence.

> So I am back to my preference: do nothing concerning passwords in the

I can live with that. I will remove the Appendix B, unless other members
disagree.

Best regards,
Badra

---

From: [email-masked]
Date: Tue, 3 Jun 2008 17:55:26 +0200 (CEST)

Dear Juergen,

Best regards,
Badra

---

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Tue, 3 Jun 2008 21:01:04 +0200

> I can live with that. I will remove the Appendix B, unless other
members

I can live with that too, go for it. 

Mehmet
___________________From [email-masked]  Tue Jun  3 12:05:41 2008
Content-class: urn:content-classes:message
Date: Tue, 3 Jun 2008 21:01:04 +0200
From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4,
	5 for Enabling Third Party Authentication using Passwords
Sender: [email-masked]

> I can live with that. I will remove the Appendix B, unless other
members

I can live with that too, go for it. 

Mehmet
_________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

__________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Charlie Kaufman <[email-masked]>
Date: Tue, 3 Jun 2008 13:59:43 -0700

Let me try to summarize what I think is being proposed and the feedback on this thread. The problem to be solved is how to pass passwords from manager to agent in the case where TLS is the encapsulating security protocol and the password is to be used with third party authentication (so the agent must get the cleartext password from the manager without depending on any special manager-accessiblFrom [email-masked]  Tue Jun  3 13:59:50 2008
From: Charlie Kaufman <[email-masked]>
To: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>,
	"[email-masked]" <[email-masked]>, "[email-masked]"
	<[email-masked]>
Date: Tue, 3 Jun 2008 13:59:43 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4,
 5 for Enabling Third Party Authentication using Passwords
Sender: [email-masked]

Let me try to summarize what I think is being proposed and the feedback on this thread. The problem to be solved is how to pass passwords from manager to agent in the case where TLS is the encapsulating security protocol and the password is to be used with third party authentication (so the agent must get the cleartext password from the manager without depending on any special manager-accessible per-user state).

Badra (in appendix B) presents 5 options:

1) Add a <user-login> RPC to NETCONF in this specific scenario in order for the manager to pass the password over the encrypted TLS connection. This is somewhat of a layer violation, since authentication is not supposed to take place in the NETCONF protocol. Given that this exchange takes place only as the first exchange after the TLS connection is set up, one could architecturally pretend that it is part of TLS rather than part of NETCONF, but it really cheating.

2) Enhance TLS to permit passing an encrypted password as part of TLS authentication. From a security perspective, this is equivalent to (1), but it is architecturally correct (and it could be used by any protocol that runs over TLS and needs this feature). It would be most properly specified by the TLS WG, and they are unlikely to do it because they disapprove of building protocols to these requirements.

3) and 5) effectively say to not support third party password authentication over TLS, but rather recommend that implementers with such requirements implement BEEP or SSH as their encapsulating security protocol instead of TLS. This is also called the "do nothing" option.

4) This is like (1) except that instead of implementing a simple <user login> RPC, it implements an encapsulation of SASL. This is more work, but might cover more scenarios should there in the future be other authentication protocols that can be encapsulated in SASL. Like (1), it is a layer violation.

My reading of this thread is that after confusion about options 3 and 5 were clarified, they were favored (by an admittedly small number of speakers).

I agree with Badra that (2) is not going to happen - at least not anytime soon - and is therefore not a plausible solution for NETCONF TLS. Whether (3) and (5) (doing nothing) is acceptable is something I can't judge. Is TLS expected to be the primary protocol for NETCONF, or will SSH be more widely used. It is certainly the easiest solution.

Between (1) and (4), I would prefer (1) because it is simpler. Until recently, (4) would have been much more politically acceptable to the Security ADs because in particular Sam Hartman was a fan of SASL. Who is your security AD now?

Another argument in favor of doing nothing for now is that TLS may eventually implement something the encapsulates SASL, and if they do you will be able to use that new feature in an architecturally clean way. If you do (1) or (4) now, it will remain as legacy for you to maintain even after TLS is fixed.

So I guess my recommendation is that you do nothing for now unless there is some urgent need and hope TLS gets enhanced before your need is urgent. If that doesn't happen, you might describe a simple option #1 in an informational or experimental RFC in order to attract less attention.

        --Charlie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich)
Sent: Tuesday, June 03, 2008 12:01 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords

Mehmet

e per-user state).

Badra (in appendix B) presents 5 options:

1) Add a <user-login> RPC to NETCONF in this specific scenario in order for the manager to pass the password over the encrypted TLS connection. This is somewhat of a layer violation, since authentication is not supposed to take place in the NETCONF protocol. Given that this exchange takes place only as the first exchange after the TLS connection is set up, one could architecturally pretend that it is part of TLS rather than part of NETCONF, but it really cheating.

2) Enhance TLS to permit passing an encrypted password as part of TLS authentication. From a security perspective, this is equivalent to (1), but it is architecturally correct (and it could be used by any protocol that runs over TLS and needs this feature). It would be most properly specified by the TLS WG, and they are unlikely to do it because they disapprove of building protocols to these requirements.

3) and 5) effectively say to not support third party password authentication over TLS, but rather recommend that implementers with such requirements implement BEEP or SSH as their encapsulating security protocol instead of TLS. This is also called the "do nothing" option.

4) This is like (1) except that instead of implementing a simple <user login> RPC, it implements an encapsulation of SASL. This is more work, but might cover more scenarios should there in the future be other authentication protocols that can be encapsulated in SASL. Like (1), it is a layer violation.

My reading of this thread is that after confusion about options 3 and 5 were clarified, they were favored (by an admittedly small number of speakers).

I agree with Badra that (2) is not going to happen - at least not anytime soon - and is therefore not a plausible solution for NETCONF TLS. Whether (3) and (5) (doing nothing) is acceptable is something I can't judge. Is TLS expected to be the primary protocol for NETCONF, or will SSH be more widely used. It is certainly the easiest solution.

Between (1) and (4), I would prefer (1) because it is simpler. Until recently, (4) would have been much more politically acceptable to the Security ADs because in particular Sam Hartman was a fan of SASL. Who is your security AD now?

Another argument in favor of doing nothing for now is that TLS may eventually implement something the encapsulates SASL, and if they do you will be able to use that new feature in an architecturally clean way. If you do (1) or (4) now, it will remain as legacy for you to maintain even after TLS is fixed.

So I guess my recommendation is that you do nothing for now unless there is some urgent need and hope TLS gets enhanced before your need is urgent. If that doesn't happen, you might describe a simple option #1 in an informational or experimental RFC in order to attract less attention.

        --Charlie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich)
Sent: Tuesday, June 03, 2008 12:01 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords

Mehmet