Posts Tagged ‘authentication’
The following question was recently sent to me regarding PPP and CHAP:
At the moment I only have packet tracer to practice on, and have been trying to setup CHAP over PPP.
It seems that the “PPP CHAP username xxxx” and “PPP CHAP password xxxx” commands are missing in packet tracer.
I have it set similar to this video… (you can skip the first 1 min 50 secs)
As he doesn’t use the missing commands, if that were to be done on live kit would it just use the hostname and magic number to create the hash?
Also, in bi-directional authentication, do both routers have to use the same password or can they be different as long as they match what they expect from the other router?
Here was my reply:
When using PPP CHAP keep in mind four fundamental things:
- The “magic number” that you see in PPP LCP messages has nothing to do with Authentication or CHAP. It is simply PPPs way of trying to verify that it has a bi-directional link with a peer. When sending a PPP LCP message a random Magic Number is generated. The idea is that you should NOT see your own Magic Number in LCP messages received from your PPP Peer. If you DO see the same magic number that you transmited, that means you are talking to yourself (your outgoing LCP CONFREQ message has been looped back to you). This might happen if the Telco that is providing your circuit is doing some testing or something and has temporarily looped-back your circuit.
- At least one of the devices will be initiating the CHAP challenge. In IOS this is enabled with the interface command, “ppp authentication chap”. Technically it only has to be configured on one device (usually the ISP router that wishes to “challenge” the incoming caller) but with CHAP you can configure it on both sides if you wish to have bi-directional CHAP challenges.
- Both routers need a CHAP password, and you have a couple of options on how to do this.
- The “hash” that is generated in an outgoing PPP CHAP Response is created as a combination of three variables, and without knowing all three values the Hash Response cannot be generated:
- A router’s Hostname
- The configured PPP CHAP password
- The PPP CHAP Challenge value
I do all of my lab testing on real hardware so I can’t speak to any “gotchas” that might be present in simulators like Packet Tracer. But what I can tell you, is that on real routers the side that is receiving the CHAP challenge must be configured with an interface-level CHAP password.
The relevant configurations are below as an example.
ISP router that is initiating the CHAP Challenge for incoming callers:
username Customer password cisco ! interface Serial1/3 encapsulation ppp ppp authentication chap ip address x.x.x.x y.y.y.y !
Customer router placing the outgoing PPP call to ISP:
hostname Customer ! interface Serial1/3 encapsulation ppp ppp chap password cisco ip address x.x.x.x y.y.y.y !
If you have a situation where you expect that the Customer Router might be using this same interface to “call” multiple remote destinations, and use a different CHAP password for each remote location, then you could add the following:
Customer router placing the outgoing PPP call to ISP-1 (CHAP password = Bob) and ISP-2 (CHAP password = Sally):
hostname Customer ! username ISP-1 password Bob
username ISP-2 password Sally
interface Serial1/3 encapsulation ppp ppp chap password cisco ip address x.x.x.x y.y.y.y !
Notice in the example above, the “username x password y” commands supercede the interface-level command, “ppp chap password x”. But please note that the customer (calling) router always needs the “ppp chap password” command configured at the interface level. A global “username x password y” in the customer router does not replace this command. In this situation, if the Customer router placed a call to ISP-3 (for which there IS no “username/password” statement) it would fallback to using the password configured at the interface-level.
Lastly, the “username x password y” command needs to be viewed differently depending on whether or not it is configured on the router that is RESPONDING to a Challenge…or is on the router that is GENERATING the Challenge:
- When the command “username X password Y” is configured on the router that is responding to the CHAP Challenge (Customer router), the router’s local “hostname” and password in this command (along with the received Challenge) will be used in the Hash algorithm to generate the CHAP RESPONSE.
- When the command “username X password Y” is configured on the router that is generating the CHAP Challenge (ISP Router), once the ISP router receives the CHAP Authentication Response (which includes the hostname of the Customer/calling router) it will match that received Hostname to a corresponding “username X password Y” statement. If one is found that matches, then the ISP router will perform its own CHAP hash of the username, password, and Challenge that it previously created to see if its own, locally-generated result matches the result that was received in the CHAP Response.
Lastly, you asked, “ Also, in bi-directional authentication, do both routers have to use the same password or can they be different as long as they match what they expect from the other router?”
Hopefully from my explanations above it is now clear that in the case of bi-directional authentication, the passwords do indeed have to be the same on both sides.
Hope that helps!
Just wanted to throw out a quick reminder to all of you involved day-to-day with Cisco Unified Communications in some fashion. Tomorrow I will host a free vSeminar on configuring and utilizing Active Directory as a source of LDAP user synchronization and authentication with the Cisco UC architecture servers.
- December 14, 2010 – 03:00 PM EST
- Instructor: Mark Snow, CCIE #14073
- Topic: LDAP Synchronization and Authentication in Unified Communications
If you still haven’t registered, you can do so right up until the webinar begins. To do so, simply click here and fill in your requested information at the bottom of the page.
In case you missed any previous vSeminars, be sure to check out the recent updates here.
Hope to see you tomorrow!
Tags: Active Directory, authentication, call-manager, CCIE Voice, CCIE Voice Bootcamp, cisco, cisco voice, communications manager, How to Pass the CCIE Voice Lab Exam, ip-phone, LDAP, Shared Success, Synchronization, telephony, unified communications, unified communications manager, voip phone
In this post, we will examine PAP and CHAP forms of PPP authentication. The emphasis here will be on the fact that these technologies are one-way in nature. So many of my CCIE-level students believe that they must be configured in a bidirectional configuration. I guess this is because it is what traditional Cisco classes always demonstrate at the CCNA and CCNP levels.
OK – I have pre-configured two routers, R1 and R2, they are connected by their Serial 0/0 interfaces. Let us begin with R1 as a PPP PAP server, and the R2 device as the PPP PAP client. If you ALWAYS think of these technologies (PAP and CHAP) in terms of CLIENT and SERVER commands, you will be in excellent shape.
The tutorial presented below is a small excerpt from the “System Management” section of beta IEWB-RS Vol I version 5.
SNMPv3 protocol a security model, defining new concepts to replace the old community-based pseudo-authentication and provide communication privacy by means of encryption. The new concepts are: user, group and security level. A group defines the access policy for a set of users. An access policy defines which SNMP objects can be accessed for reading and writing or which SNMP objects can generate notifications to the members of a group. Policy is defined by associating the respective read, write or notify view with a group. By using a notify view, a group determines the list of notifications its users can receive. A group also defines the security model and security level for its users.
Essentially, all groups form a table, which maps users to their read/write/notify views and security models. Note that if a group is defined without a read view than all objects are available to read. Contrary to that, if no write or notify view is defined, no write access is granted and no objects can send notifications to members of the group. The notify view is usually not configured manually. Rather, it’s added by the snmp-server host command automatically, when a users in a group is bound to a notification target host. Note that SNMP will use the username configured with snmp-server host along with the security model specified to authenticate and possibly encrypt the notifications. If the security model is set to «noauth» then a plain username is sent in a manner resembling the old community string.
The following security models exist: SNMPv1, SNMPv2, SNMPv3. The following security levels exits: “noAuthNoPriv” (no authentiation and no encryption – noauth keyword in CLI), “AuthNoPriv” (messages are authenticated but not encrypted – auth keyword in CLI), “AuthPriv” (messages are authenticated and encrypted – priv keyword in CLI). SNMPv1 and SNMPv2 models only support the “noAuthNoPriv” model since they use plain community string to match the incoming packets. The SNMPv3 implementations could be configured to use either of the models on per-group basis (in case if “noAuthNoPriv” is configured, username serves as a replacement for community string). All users sharing a group utilize the same security model, however, the specific model settings (password, encryption key) are sep per-user. Note that SNMPv3 does not send passwords in clear-text and uses hash-based authentication with either MD5 or SHA1 functions (HMAC authentication – the packet conted is hashed along with authentication key to produce the authentication string). For encryption, statically configured keys are used along with DES56 symmetric cipher (that mean the same key should be configured on NMS for the particular user).
Consider the example below. Three groups are created. Groups «NORMAL» and «RESTRICTED» are used to control remote users access and group «TRAP» is used to send notifications. Note that only read-view is specified for group “RESTRICTED” and it’s limited to IfEntry fields for a fixed interface index. The group «RESTRICTED» has an access-list applied to control the NMS stations the users can access from. Note that the groups have different security levels. Next, three users are created, one for each group respectively, with their authentication and encryption keys. Finally, SNMP link up and down notifications are enabled and SNMP trap destination host is configured. This operation automatically creates and assigns the «notify» view for the respective group (will appear in show commands output below).
! ! Access-List to control users in the RESTRICTED group. ! access-list 99 permit 22.214.171.124 0.0.0.255 ! ! Set ifIndexes persistent, for view definition is based on IfIndexes ! snmp-server ifindex persist ! ! The first view covers the “ISO” sub-branch and the second one covers ! all “lifEntry” fields for interface with IfIndex 3 (Serial 0/0). ! snmp-server view NORMAL iso included snmp-server view RESTRICTED ifEntry.*.3 included ! ! Define three groups. The first one allows to read and write ! into a large portion of the MIB tree. The second one allows reading ! just information specific to Serial 0/0 interface, and limits user ! access based on access-list ! ! The third group is for sending traps. A user belonging to this group ! will be utilized to send trap messages. Its name and password ! will be used to create authentication credentials in a trap message ! and the users privacy password will be used to encrypt the packet. ! Note that this group has NO notify view defined, which is done on ! on purpose. The notify view will be automatically populated when ! notification hosts are configured and bound to users ! snmp-server group NORMAL v3 priv read NORMAL write NORMAL snmp-server group RESTRICTED v3 auth read RESTRICTED access 99 snmp-server group TRAP v3 priv ! ! Users, their passwords and encryption keys are defined now ! snmp-server user NORMAL NORMAL v3 auth sha CISCO priv des56 CISCO snmp-server user RESTRICTED RESTRICTED v3 auth sha CISCO snmp-server user TRAP TRAP v3 auth sha CISCO priv des56 CISCO ! ! Allow sending traps and configure a destination host. Note that when ! a host is configured and bound to SNMPv3 username, the corresponding ! group notify view is populated based on traps allowed for this ! particular destination. This is why it’s not required to configure ! the notify view for a group. ! snmp-server enable traps snmp linkup linkdown snmp-server host 126.96.36.199 traps version 3 priv TRAP
Perform some basic verifications next using the show commands. Note that SNMPv3 users do not appear in the running configuration for security reason (different management channel) but you can see some information using show snmp users command. Also, pay attention to the automatic view assigned to the “TRAP” group.
Rack1R6#show snmp user User name: TRAP Engine ID: 80000009030000119221DA80 storage-type: nonvolatile active Authentication Protocol: SHA Privacy Protocol: DES Group-name: TRAP User name: NORMAL Engine ID: 80000009030000119221DA80 storage-type: nonvolatile active Authentication Protocol: SHA Privacy Protocol: DES Group-name: NORMAL User name: RESTRICTED Engine ID: 80000009030000119221DA80 storage-type: nonvolatile active Authentication Protocol: SHA Privacy Protocol: None Group-name: RESTRICTED Rack1R6#show snmp group groupname: ILMI security model:v1 readview : *ilmi writeview: *ilmi notifyview:
row status: active groupname: ILMI security model:v2c readview : *ilmi writeview: *ilmi notifyview: row status: active groupname: TRAP security model:v3 noauth readview : writeview: notifyview: *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F row status: active groupname: TRAP security model:v3 priv readview : v1default writeview: notifyview: row status: active groupname: NORMAL security model:v3 priv readview : NORMAL writeview: NORMAL notifyview: row status: active groupname: RESTRICTED security model:v3 auth readview : RESTRICTED writeview: notifyview: row status: active access-list: 99 Rack1R6#show snmp view *ilmi system - included permanent active *ilmi atmForumUni - included permanent active NORMAL iso - included nonvolatile active v1default iso - included permanent active v1default internet.6.3.15 - excluded permanent active v1default internet.6.3.16 - excluded permanent active v1default internet.6.3.18 - excluded permanent active v1default ciscoMgmt.394 - excluded permanent active v1default ciscoMgmt.395 - excluded permanent active v1default ciscoMgmt.399 - excluded permanent active v1default ciscoMgmt.400 - excluded permanent active RESTRICTED ifEntry.0.3 FF:EF included nonvolatile active *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F iso.2.840.10036 - included volatile active *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F internet - included volatile active